Opened 12 years ago

Closed 12 years ago

Last modified 12 years ago

#4407 closed defect (fixed)

dijit/_base/place.js: viewport height calculation fix

Reported by: guest Owned by:
Priority: high Milestone: 1.0
Component: Dijit Version: 0.9
Keywords: Cc:
Blocked By: Blocking:

Description

Before it was

               w = _document.body.clientWidth<=_window.innerWidth ? _document.body.clientWidth:_document.documentElement.clientWidth;;
               // _window.innerHeight includes the height taken by the scroll bar
               // clientHeight is ideal but does not exist for window
               h = _document.body.clientHeight<=_window.innerHeight ? _document.body.clientHeight:_document.documentElement.clientHeight;

I changed it to:

		// The _document.documentElement.* properties seem to return the proper size always,
		// they even exclude the scroll bar size if one exists and they also really 
		// measure the height of the available area independent of the content styling.
		// (I had the problem that the content part of the page was floating and that
		// was not taking into account by document.body.clientHeight).
		w = _document.documentElement.clientWidth;
		h = _document.documentElement.clientHeight;

Attachments (1)

viewport-height-fixx.diff (1.2 KB) - added by guest 12 years ago.
viewport height fix

Download all attachments as: .zip

Change History (10)

Changed 12 years ago by guest

Attachment: viewport-height-fixx.diff added

viewport height fix

comment:1 Changed 12 years ago by guest

for the record I proposed the patch wolfram.kriesing@…, guest might not have a CLA :-)

comment:2 Changed 12 years ago by bill

Component: GeneralDijit
Milestone: 1.0
Owner: anonymous deleted

But that code was just recently changes (see [10334] and [10345]) to fix #4045. Doesn't your change make that bug recur?

comment:3 Changed 12 years ago by bill

Summary: Viewport height calculation fixdijit/_base/place.js: viewport height calculation fix

And also, does your change fix a bug? If so can you give the testcase?

comment:4 Changed 12 years ago by guest

see the comment in the patch: I had the problem that the content part of the page was floating and that was not taken into account by document.body.clientHeight

comment:5 Changed 12 years ago by haysmark

When I was fixing #4045, I tried using documentElement. It does not regress #4045 per se, but what happens is the documentElement height in that dojox test is like 200px or something so the ComboBox? drop down ALWAYS appears above the ComboBox?, which looks totally wrong.

Bill, I know how much you love ComboBox? popups appearing above the ComboBox?, so if you want that happening go ahead and commit this. Otherwise just say no.

comment:6 Changed 12 years ago by wolfram

Well, its funny. I also have the combobox popup appear above the combobox sometimes (I also opened this ticket). And I will investigate it. I am just wondering if that can be the reason to leave the height value wrong for other cases ... I will try some test cases and find solutions for occuring problems, input in the form of test cases would be very welcome.

Wolfram

comment:7 Changed 12 years ago by bill

Milestone: 1.01.1

OK. Keep in mind the the popup is sometimes supposed to appear above the ComboBox?, but only when there isn't "enough room" below the ComboBox?. Of course, "enough room" is a vague concept since the drop down can scroll (by clicking "more choices"), but anyway, if the drop down list is very short (just a few items, with no "more choices" button), and it appears above when it could have fit below, then that illustrates the bug the Mark is talking about.

comment:8 Changed 12 years ago by bill

Resolution: fixed
Status: newclosed

OK, hopefully this is all fixed with [10680], and I also added tests in dijit/tests/_base/viewport*.html. If not please reopen and assign to haysmark.

comment:9 Changed 12 years ago by bill

Milestone: 1.11.0
Note: See TracTickets for help on using tickets.