IE11 does not maintain scroll position when applying class with display: none

[Michael Schall]

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.

[bill]

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? with noLayout=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 the position: absolute CSS setting depends on the parent node having position: 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.

[Michael Schall]

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.

[bill]

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 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.

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).

[bill]

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.

[Michael Schall]

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.

[bill]

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.

[bill]

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.

[Bill Keese <[email protected]…>]

In 534157f1ce7473697bd3587d7b39248f50d0ac9e/dijit:

Error: Processor CommitTicketReference failed

Unsupported version control system "git": Can't find an appropriate component, maybe the corresponding plugin was not enabled? 

[Michael Schall]

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."

[bill]

OK, thanks for the info! It's good to have a "fallback plan" if visibility:hidden turns out to be too problematic.

[wkeese <[email protected]…>]

In 520250b/dijit:

Error: Processor CommitTicketReference failed

Unsupported version control system "git": Can't find an appropriate component, maybe the corresponding plugin was not enabled?