Opened 4 years ago

Closed 4 years ago

Last modified 3 years ago

#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 4 years ago by bill

Milestone: tbd1.11
Status: newassigned

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.

comment:2 Changed 4 years ago by 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.

Last edited 4 years ago by Michael Schall (previous) (diff)

comment:3 Changed 4 years ago by 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).

comment:4 Changed 4 years ago by 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.

comment:5 Changed 4 years ago by 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.

Last edited 4 years ago by Michael Schall (previous) (diff)

comment:6 Changed 4 years ago by 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.

comment:7 Changed 4 years ago by 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.

Last edited 4 years ago by bill (previous) (diff)

comment:8 Changed 4 years ago by Bill Keese <bill@…>

Resolution: fixed
Status: assignedclosed

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? 

comment:9 Changed 4 years ago by 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."

comment:10 Changed 4 years ago by bill

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

comment:11 Changed 3 years ago by wkeese <bill@…>

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? 
Note: See TracTickets for help on using tickets.