#18612 closed defect (fixed)
IE11 does not maintain scroll position when applying class with display: none
Reported by: | Michael Schall | Owned by: | bill |
---|---|---|---|
Priority: | undecided | Milestone: | 1.11 |
Component: | Dijit | Version: | 1.10.4 |
Keywords: | Cc: | ||
Blocked By: | Blocking: |
Description
IE11 does not keep the scroll position of scrollable items if a parent element is hidden and then shown by adding and then removing a class containing display:none.
I have a jsfiddle showing the issue with dgrid in a TabContainer?, and then some simple examples with divs.
Firefox also currently resets the scroll if the scrollable item is within an iframe.
I know this is a significant change, but a potential workaround is to change how the class hides the element. The following seems to work:
.dijitHidden { position: absolute; /* remove from normal document flow to simulate display: none */ visibility: hidden; /* hide element from view */ }
I sent a message to the Interest mailing list.
I have also opened a Connect ticket with Microsoft.
Change History (11)
comment:1 Changed 6 years ago by
Milestone: | tbd → 1.11 |
---|---|
Status: | new → assigned |
comment:2 Changed 6 years ago by
I was thinking of suggesting a different class but I was surprised to see dijitHidden is only used by the StackContainer/AccordionContainer?/_ContentPaneResizeMixin internally.
The comments in the code call out this class is for "StackContainer? etc." But who reads comments. :)
.dijitHidden { /* To hide unselected panes in StackContainer etc. */ display: none !important; } .dijitVisible { /* To show selected pane in StackContainer etc. */ display: block !important; /* override user's display:none setting via style setting or indirectly via class */ position: relative; /* to support setting width/height, see #2033 */ }
I suppose users of dijit may be relying on it as written. Creating a new class is definitely more backward compatible. Sounds good to me. dijitInvisible
?
I don't think I understand your position:absolute
and position: relative
statement.
Looking at Mozilla documentation. It states if a parent is not found it will use the "initial container" other sites state that is the HTML element. My example doesn't have any position: relative
elements.
comment:3 Changed 6 years ago by
I was thinking of suggesting a different class but I was surprised to see dijitHidden is only used by the StackContainer/AccordionContainer?/_ContentPaneResizeMixin internally.
The comments in the code call out this class is for "StackContainer? etc."
OK that's a good point, maybe it's not worth making a new class.
I don't think I understand your
position:absolute
andposition: relative
statement. Looking at Mozilla documentation. It states if a parent is not found it will use the "initial container" other sites state that is the HTML element. My example doesn't have any position: relative elements.
Hmm, I agree that according to that documentation setting position:relative
shouldn't be necessary, but I found it to be necessary for the Editor, see https://github.com/dojo/dijit/blob/96bd828e5756f7f1f7408d2d05e7b538fde155df/_editor/plugins/ViewSource.js#L176. When I didn't set position:relative
on the parent node, the <iframe>
(hidden with visibility:hidden position:absolute
) ended up flowing after it's previous sibling, the <textarea>
node).
comment:4 Changed 6 years ago by
One other thing: the layout widgets have code to call resize() on all the subwidgets the first time a pane is shown. Because the subwidgets can't lay themselves out inside a display:none container, so they need to wait until the pane is visible. Seems like that all changes now.
comment:5 Changed 5 years ago by
What direction are you planning on going? I have code working for the 1.6 branch using modified dijitHidden
, but will move to dijitInvisible
(like that name?) if you want. I need to move this to production for a client.
comment:6 Changed 5 years ago by
Oh, probably just change the definition of dijitHidden, like you suggested originally. I need to test it and see if it works, and also fix any spurious regression test failures.
comment:7 Changed 5 years ago by
FYI, I researched the history of this. See #5672, a failed attempt to use visibility:hidden
rather than display:none
. However, the failure was due to a problem in IE6 (and likely IE7), which AFAICT doesn't happen in IE8+, so I think we are OK.
comment:8 Changed 5 years ago by
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
comment:9 Changed 5 years ago by
I opened a Connect Issue with Microsoft when I found this issue.
It was just closed and is now fixed in Edge, however "We're not presently working on feature bugs in Internet Explorer outside of security-related issues."
comment:10 Changed 5 years ago by
OK, thanks for the info! It's good to have a "fallback plan" if visibility:hidden turns out to be too problematic.
I implemented something like this for #18607.
Changing TabContainer? to hide children via
visibility:hidden
sounds reasonable. Need to be careful not to break TabContainers? withnoLayout=true
though. In that case the visible pane needs to continue to control the TabContainer?'s height, regardless of other hidden panes that may be taller.I'm reluctant to change the definition of
dijitHidden
since that could possibly break other code using that CSS class. In particular, it seems like theposition: absolute
CSS setting depends on the parent node havingposition: relative
, yet there's no reason to assume it does.Also, note that this ticket is a superset of #17800, so fixing this will fix #17800.