Opened 7 years ago

Closed 7 years ago

#15571 closed defect (worksforme)

window.getBox not working correctly when used inside a window resize handler?

Reported by: Paul Christopher Owned by:
Priority: undecided Milestone: tbd
Component: Core Version: 1.7.3
Keywords: Cc:
Blocked By: Blocking:

Description

Not sure whether this is a bug or a result of an interaction between dojo/window.getBox and a callback which reacts on window resizes. However the result is the same on different browsers: FF13, IE9: the viewport size seems not to be calculated correctly in all cases.

Description

When resizing a window, a callback is fired, see attached test case. The handler gets the current viewport dimensions with dojo/window.getBox and prints them to the console. However the calculation of the viewport size seems not to be correct in all cases. Espcially if you use the "restore down"/ "maximize" button (which is next to the close button) so as to make the browser window smaller, the viewport seems not to be calculated correctly:

When gradually resizing the window by gripping the border of the window, sometimes values seem not to be calculated correctly: There are some outliers, too.

Steps to reproduce the issue

  • Run the attached test case. The test case prints the viewport dimension to the console. Moreover it shows a gray rectangle which dimensios are 0,0,viewport.w-20px, viewport.h-20px. Start with a maximized browser window. Now use the "restore down" button so as to make the window smaller. In most cases, the margin is too big, bigger than viewport-20px.
  • Now gradually resize the window. There are outliers, too: The margin between the gray box and the browser window is not always the same, but jumps significantly sometimes.

Affected browser

Happens to me with Firefox13 and IE9.

Attachments (3)

testViewportCalculation.html (1.3 KB) - added by Paul Christopher 7 years ago.
screenshot1.png (115.4 KB) - added by Paul Christopher 7 years ago.
screenshot2.png (207.9 KB) - added by Paul Christopher 7 years ago.

Download all attachments as: .zip

Change History (8)

Changed 7 years ago by Paul Christopher

Changed 7 years ago by Paul Christopher

Attachment: screenshot1.png added

Changed 7 years ago by Paul Christopher

Attachment: screenshot2.png added

comment:1 Changed 7 years ago by bill

Hmm, sounds like you just need a setTimeout() to delay the calculation? I doubt it's something dojo can fix.

According to your description though dijit/Viewport.js wouldn't work either. Is it working for you? Like when you resize a full-screen app (like our themeTester.html test page, or demos/mail/demo.hml demo), does everything redraw correctly?

comment:2 Changed 7 years ago by Paul Christopher

Yes, Bill, you are right: It is nothing Dojo can fix. The viewport value "jumps" because a scroll bar has been shown for a very short moment of time and has been hidden immediately. However while the scrollbar was shown, the viewport was calculated (including the scroll bars). That's all. Everything is fine with Dojo. So I don't mind closing this issue as invalid. Thanks for the response and have a good day!

comment:3 Changed 7 years ago by bill

I'm wondering though if dijit/Viewport.js is showing the same problem; if so I should add a setTimeout() in there.

comment:4 Changed 7 years ago by Paul Christopher

Bill, I think it is really an issue of my test case only:

  • There is a <div> with a fixed width, say 1000px.
  • The browser window gets resized, i.e. is made smaller. This causes the browser to display some scroll bars since the size of the <div> doesn't fit in the viewport anymore.
  • The resize event sets the width of the <div> back to the width of the viewport-10px
  • Now the <div> fits in the viewport. However this causes the scroll bars to be hidden again.
  • Unintended result: The layout is not correct anymore: The margin is too big, i.e. not viewportWidth-10px, see screnshot1.png, because hiding of the scroll bars has not be taken into account.

To fix this behaviour, I simply need to call doLayout() twice or set overflow:hidden so as to get rid off scroll bars at all.

comment:5 Changed 7 years ago by bill

Resolution: worksforme
Status: newclosed

I see... yah makes sense, sounds like overflow:hidden is what you want. I'll close this ticket, although not sure if I should mark it "invalid" or "wontfix" or what.

Last edited 7 years ago by bill (previous) (diff)
Note: See TracTickets for help on using tickets.