Opened 8 years ago

Closed 8 years ago

#12317 closed defect (fixed)

[regression] popups fail to appear in IE8 if insufficent space

Reported by: Caleb Maclennan Owned by:
Priority: high Milestone: 1.6
Component: Dijit Version: 1.6.0b1
Keywords: Cc:
Blocked By: Blocking:

Description (last modified by bill)

The test case in dijit/tests/TooltipDialogLarge.html is sufficient to demonstrate. In IE8, if you resize the window vertically to less than the height of the expected TooltipDialog, nothing at all will pop up.

Attachments (1)

TooltipDialogEdge.html (1.8 KB) - added by Caleb Maclennan 8 years ago.
Test that shows failing DropDownButton? widgets in IE8 both above and below, both TooltipDialog? and simple div.

Download all attachments as: .zip

Change History (20)

comment:1 Changed 8 years ago by bill

Description: modified (diff)
Milestone: 1.6future
Summary: TooltipDialog fails to appear in IE8 if insufficent spaceTooltipDialog: fails to appear in IE8 if insufficent space

We don't really support large TooltipDialogs. There's code for Dialog to shrink the Dialog to fit on the screen but nothing for TooltipDialog, so even if it did show up it wouldn't be very useful since the user couldn't see the whole thing.

comment:2 Changed 8 years ago by Caleb Maclennan

This is a regression issue. It worked fine in dojo 1.4 and 1.5 and still works fine in other browsers. If just draws where it can and the window canvas grows to accomidate if need be. Failure to draw anything at all breaks previous apps.

The tooltip doesn't really need to be large. I ran into this problem on one that was just a couple em's heigh but happened to be launched from near the edge of the page.

comment:3 Changed 8 years ago by bill

Milestone: future1.6

I see.

Hmm, well a TooltipDialog should definitely appear on the screen if there's room on one side of the button or the other. Looking at DropDownButton now though it looks like dropDownPosition should have a few more entries (i.e. a few more positions to try), does your TooltipDialog appear correctly if you have:

<button dojoType=dijit.form.DropDownButton
  dropDownPosition="below,below-alt,above,above-alt,after,before">

If not please attach your test case (where the small TooltipDialog launched from the edge of the page doesn't show up).

As for TooltipDialogs that are really large, that's harder to fix, and not sure why it changed from 1.5 or why the behavior is different on IE8 vs. other browsers, but I'll look at it.

comment:4 Changed 8 years ago by Caleb Maclennan

A couple notes:

Setting that dropDownPosition makes all browsers go screwy. In my app they render the dropdowns using the "above" attribute starting from window.y=0

IE fails in TooltipDialogLarge?.html test page but succedes in the same thing at test_TooltipDialog.html. I think the difference must be not so much the size of the window as the size of the current drawn canvas. In my app I am using BorderContainer? layout, so the canvas stops at the edge of the window. In most browsers, tips will expand the canvas and render below that edge if they run out of space, but in IE8 they just don't show up. I'll try to work up a simple test case for this.

comment:5 Changed 8 years ago by Caleb Maclennan

This does not seem to be a TooltipDialog? problem after all but a DropDownButton? problem. Using a ContentPane? or some other widget as the drop down content has the same effect.

comment:6 Changed 8 years ago by bill

Also, there is no dijit/tests/TooltipDialogLarge.html file, that's something I attached to a ticket but I can't find it now.

Changed 8 years ago by Caleb Maclennan

Attachment: TooltipDialogEdge.html added

Test that shows failing DropDownButton? widgets in IE8 both above and below, both TooltipDialog? and simple div.

comment:7 in reply to:  6 Changed 8 years ago by Caleb Maclennan

Replying to bill:

I attached to a ticket but I can't find it now.

I just attached a test derived from yours that shows a couple similar cases including one that is not a TooltipDialog?.

comment:8 Changed 8 years ago by bill

The "Edge menu" button is showing up fine for me on IE8, it's not showing up for you?

comment:9 Changed 8 years ago by Caleb Maclennan

It fails to show up if the window is smaller than the height of the menu. If you add a <div style="height: 400px"></div> outside of the BorderContainer? just before the closing body tag to force the canvas to be larger than the viewport, the menu pops up just fine.

Also, the property you mentioned of "dropDownPosition" for the button does not seem to be obeyed at all.

The basic problem seems to be that durring detection of where there might be space to put a popup, the dojo code for most browsers comes to the conclusion that there isn't viewport space but just draw it anyway and let the browser canvas grow, while the code for IE (at least v8, maybe earlier too) decides to give up and not draw anything at all.

comment:10 Changed 8 years ago by Caleb Maclennan

Even more interesting: I mentioned adding a div outside the bordercontainer to force a larger canvas changed the behavior of the menu. What I didn't realize is that you don't actually ahve to make the canvas large enough for the popup to fit, all you have to do is make it larger than the browser viewport. Adding <div style="height: 1px"></div> right before the closing body tag will force IE to behave. Even in a tiny-tiny browser window, the canvas will grow to fit the size of the popup!

This bug is only triggered when the canvas_size <= viewport_size. As long as the canvas is larger than the viewport to start with, it will continue to grow to accomidate new content drawn by dojo popups.

comment:11 Changed 8 years ago by bill

OK, so your comment from before:

The tooltip doesn't really need to be large. I ran into this problem on one that was just a couple em's heigh but happened to be launched from near the edge of the page.

AFAICT it does need to be large. The only thing your test case is showing is a problem when the tooltip can't fit within the viewport, either above or below the button. Is there any other problem you are seeing?

This bug is only triggered when the canvas_size <= viewport_size

There's no such thing as a "canvas" here, I guess you are talking about the document size.

Also, the property you mentioned of "dropDownPosition" for the button does not seem to be obeyed at all.

If you have a test case where it isn't being obeyed please file a separate ticket, attaching the test case.

comment:12 in reply to:  11 Changed 8 years ago by Caleb Maclennan

AFAICT it does need to be large. The only thing your test case is showing is a problem when the tooltip can't fit within the viewport, either above or below the button. Is there any other problem you are seeing?

Yes, but I can't figure out what is different in my devel app from what I can replicate in a test-case. When I do I will post, but I have had things not show up that would have been smaller than the document, although that might be a different bug.

There's no such thing as a "canvas" here,

Sorry, wrong diction. Yes document size sounds right.

If you have a test case where it isn't being obeyed please file a separate ticket

The test case I just posted has the drop down position for the button in the botton pane set to "below", yet since most browser window senarios only have room above it gets draw there. Since I don't see that property in the api docs I'm not sure if I'm using it wrong or if it is just supposed to be a priority suggestion, not a hard rule or what. It would be easier to file a ticket if its clearer to me what was supposed to happen. Is there a 1.6 api docs site?

comment:13 Changed 8 years ago by bill

OK, understood. About "dropDownPosition" it's just a bug in your test case, that parameter is an array of strings not a single string. It should thus be:

<div id="edgeButton" data-dojo-type="dijit.form.DropDownButton"
    data-dojo-props='dropDownPosition:["below"] '>

Of course there's no room below "edgeButton" so that won't be useful, but anyway that's how you use dropDownPosition.

Sorry, the 1.6 API docs aren't posted yet, need to wait until the release.

comment:14 Changed 8 years ago by bill

I looked into the problem where you can't open a popup that overflows the viewport:

In 1.6, there's code to close open popups when the browser window is resized. A resize is detected by an onresize event on window, and double-checked by calling dojo.window.getBox() and comparing the result to a previous call.

When the popup is shown it unfortunately causes an onresize event on IE, even though the browser window wasn't resized. No such event on FF. And getBox() returns a slightly smaller width than before because a scrollbar has suddenly appeared on the right hand side. Although the browser window size hasn't changed size, the viewport is a little narrower.

So you could work around this problem by setting overflow:scroll on <html>, so that the scrollbar is always visible. I'm not sure [yet] how to fix this problem without such a workaround.

comment:15 Changed 8 years ago by Caleb Maclennan

Thanks for looking into this Bill.

Perhaps there is a way we can add an edge case for IE that, having confimed the window size changed, checks whether that change was strickly due to the addition of a scroll bar. If there is not a simple detection method for whether a document has a scrollbar, it could be found by first noting whether the document was larger than the viewport before vs whether it has become larger after the last resize event. I'm not sure how to code that cleanly, but IE's behavior here is pretty broken and needs some patching up. Perhaps not firing the close popups command within a certain timeout of having launched a popup? Ok ya that's ugly.

I would appear that the resize event does not fire even in IE unless the document actually grows larger than the viewport. Popups work fine even from tiny documents that have to grow as long as that growth doesn't hit the viewport edge.

For the moment I patched one app by forcing the document to be 1px larger than the viewport and setting overflow:hidden. I suppose forcing overfow:scroll would actually be a better solution, but it was a start and improvement over not having any popup at all.

comment:16 Changed 8 years ago by bill

I agree, could check if the size of the document itself changed. Or the hack you mentioned about ignoring resize events immediately after opening a popup. I was also thinking about putting in a 25px grace zone (ie, ignoring small size changes). Will think about all those options.

comment:17 Changed 8 years ago by jameyg

Two things: One, should this be retitled to reflect dijit.popup vs. TooltipDialog?. Two, this should actually be classified as regression. Comments for this new code seem to apply more to the "around" variant of dijit.popup.open (where the parent may change position), but it doesn't seem to apply to an absolutely positioned popup and still may do more harm than good when the parent position hasn't actually changed. The "not so edge" case is what I normally call the "netflix hover description" - that is, intentionally large blocks of text which could cause scrollbars.

As to whether IE is broken....the addition of the scrollbars could trigger a relayout which could shift the parent's position. So it would seem that the reason for this new block is actually benefitted by IE's behavior. If this is left in, could the check instead be changed to the parent's position changing vs. the viewport size changing?

comment:18 Changed 8 years ago by bill

Summary: TooltipDialog: fails to appear in IE8 if insufficent space[regression] popups fail to appear in IE8 if insufficent space

Yeah, eventually I'll change the code to check for the aroundNode's position changing, and actually in that case rather than closing the popup it will reposition it.

For the 1.6 release though I'll just back out my changes to close popups on screen resize / scroll. They seem to be doing more harm than good.

comment:19 Changed 8 years ago by bill

Resolution: fixed
Status: newclosed

(In [23866]) Changes related to closing/repositioning popups on scroll / resize:

  • Rollback (erase) code to close popups on window resize (refs #5777, fixes #12317) and mouse wheel (refs #12297).
  • When possible, don't close popups when the browser window is scrolled using the mouse on the browser scroll bar. Popups still close by clicking anywhere else on the page, including inner scrollbars. Unfortunately on IE6 & 7, clicking the browser scrollbar also still causes popups to close.
  • In RTL mode, make place.js set popup.style.right rather than popup.style.left, so that on screen resize (at least in the common case) the popup and the aroundNode stay aligned. (refs #10875)

Background:

  • It's often harmful that resizing a window closes the popup; the user may be expanding the window to see all of the popup. Although resizing can cause a reflow, separating the aroundNode from the popup, but often it doesn't. The case of centered/right-aligned elements mentioned in #5777 is an exception.
  • Closing popups on scroll is also questionable. Scrolling the main window will scroll the aroundNode and the popup together, so it's counterproductive to close the popup. OTOH, scrolling a <div> will separate the aroundNode from the popup. And for a mousewheel event it's hard to tell whether it's affecting the main window or a nested <div>.

In the future, I'll add code to actually reposition popups when a browser window resize or a scroll has caused the aroundNode to move.

!strict.

Note: See TracTickets for help on using tickets.