Skip to content
This repository has been archived by the owner on Sep 5, 2024. It is now read-only.

element.focus() in $mdSidenav causes page jump #1891

Closed
nolandubeau opened this issue Mar 12, 2015 · 23 comments
Closed

element.focus() in $mdSidenav causes page jump #1891

nolandubeau opened this issue Mar 12, 2015 · 23 comments

Comments

@nolandubeau
Copy link

Hi,
I am building an application which has a layout similar to the angular material design site. At the very top of the page however, is another md-toolbar. Below the first toolbar is the sidenav and the main content area.

With a layout like this when the sidenav is finished opening, element.focus() is called. This causes the page to focus to the sidenav toolbar top, and causes the toolbar above the sidenav to be partially visible (since the page has scrolled). Is it really necessary to have the element.focus() in the updateIsOpen function? If I comment out element.focus(), the issue is fixed.

if (scope.isOpen) {
//element.focus();
}

@marcysutton
Copy link
Contributor

Focus is necessary for accessibility purposes, so that keyboard and screen reader users are directed into sidenav when it opens. Sounds like we may need to do some CSS wrangling to support both use cases. Can you provide a Codepen or Plunker with your markup showing the jump?

@ThomasBurleson ThomasBurleson modified the milestone: 0.9.0 Mar 12, 2015
@marcysutton marcysutton added the needs: demo A CodePen demo or GitHub repository is needed to demonstrate the reproduction of the issue label Mar 12, 2015
@davidvthecoder
Copy link

I am also having this issue, I do not want it to snap, is there a way to override this behavior? I do not want the sidenav to "snap" causing the page to jump.

Here is a link to an example of the "snapping":
http://codepen.io/anon/pen/jEdKwv
I can confirm that if you comment out that line it stops the focus, however this isn't a solution for me as modifying angular itself will not work with our deployment strategy (not to mention its bad practice).

@davidvthecoder
Copy link

Perhaps a fix like this would work:

              var x = window.scrollX, y = window.scrollY;
              elemment.focus();
              window.scrollTo(x, y);

http://stackoverflow.com/questions/4963053/focus-to-input-without-scolling

@marcysutton
Copy link
Contributor

Smooth scrolling is something I've done in the past. That makes it so you can still focus an element and while smoothing out the jump.

@marcysutton marcysutton self-assigned this Mar 25, 2015
@davidvthecoder
Copy link

Except thats not the desired effect, why force scrolling? could we have it as an optional config property? I think most people would just want the side nav to slide out and thats it.

I would say if people want it to scroll smoothly down, they could just write their own javascript to do it.

It just seems to go away from being extensible if you force scrolling. You could implement no scrolling/no snapping and then if someone wants to smooth scroll, they could add an event to handle it. Just my 2 cents.

@marcysutton
Copy link
Contributor

The scrolling would only be added to smooth out focus, which is required for the sidenav component but causes a jump if it the element being focused is in a different area of the viewport. I'm looking into how to make this better while still keeping it accessible for keyboard and screen reader users.

@davidvthecoder
Copy link

I guess, I wonder why its required to scroll, to me it would make sense to have two behaviors. One that doesn't scroll but still focuses, and one that focuses and scrolls. Could be set by a config property on the side nav.

@dmackerman
Copy link

This is actually causing us issues in our app, because we want to focus inputs when the sidenav opens - and it appears that this is overriding that for us.

@davidvthecoder
Copy link

Or at the very least have an option that disables focus entirely, that way for those who want to create their own focus behavior rather than being forced into one way, could do that. Just have a warning that if you remove focus it will break screen readers until you implement your own. This would fix every issue, with the caveat that in documentation you would have to warn the end user about the possibility of breaking screen readers temporally.

@marcysutton
Copy link
Contributor

Ok, this sounds like a good candidate for more options. The $mdDialog has a similar configurable property with an accessibility warning in the docs, focusOnOpen.

@davidvthecoder
Copy link

👍

marcysutton pushed a commit that referenced this issue Mar 31, 2015
@marcysutton marcysutton removed the needs: demo A CodePen demo or GitHub repository is needed to demonstrate the reproduction of the issue label Apr 1, 2015
@marcysutton
Copy link
Contributor

So the issue with scrolling is that the sidenav could be inside of a scrolled element, complicating the calculated offset top. I'll keep working on it, but I'm hoping the override introduced in #2108 will be enough of a fix for this issue. Let me know.

@williamverdolini
Copy link

I'm using the latest version, but It seems to me that this issue is still open...I made a plunker to see the bug. When I open the menù from toggle, the page focuses on sidenav and scroll to it. how to prevent this scroll?

@koshuang
Copy link

koshuang commented Jul 3, 2015

+1

@chris-carrington
Copy link

Currently the sidenav is position absolute so it's at the top of the page when it comes in. So when it's focused you scroll to the top. Make it position fixed so when the focus happens it's already in view and goes no where. No js overrides required

md-sidenav {
  position: fixed;
}

@ThomsCass
Copy link

+1

override with css doesn't work for me

@nicolasletoublon
Copy link

  • 1

@gambolputty
Copy link

+1

@maximelafarie
Copy link

+1

@bamtron5
Copy link

md-options="'{focus: top}'"

Something like that. I will css this for now. +1 and thank you.

@midhunadarvin
Copy link

The overide with CSS doesn't work for me. I would like my design to remain as such, i don't want to mess with my CSS. It's just the focus behaviour that i would like to turn off. Can this be implemented?

@tellyipock
Copy link

I'm dealing with the same problem now. Any solutions besides position: fixed; ?

@angular angular locked as resolved and limited conversation to collaborators May 10, 2019
@Splaktar
Copy link
Member

@midhunadarvin @tellyipock please open a new issue with a CodePen reproduction.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests