Opened 13 years ago

Closed 12 years ago

#7449 closed enhancement (wontfix)

setViewportDimension Contribution

Reported by: ole Owned by: dante
Priority: high Milestone: future
Component: Core Version: 1.1.1
Keywords: Cc: bill, [email protected]
Blocked By: Blocking:



I'm attaching a utility function for setting the viewport dimensions. It takes width and height arguments, then adjusts the height argument to account for the height of the browser toolbar/menu area, and calls window.resizeTo width the new height, and the width argument.

Attachments (1)

browser.js (2.0 KB) - added by ole 13 years ago.

Download all attachments as: .zip

Change History (16)

Changed 13 years ago by ole

Attachment: browser.js added

comment:1 Changed 13 years ago by ole

Just noting that I put getViewport() that setViewportDimensions uses, in browser.js as well. It's being moved in the future, per ticket:

comment:2 Changed 13 years ago by James Burke

Cc: bill added

Bill, there are some viewport functions in dijit, is that right? How does this patch overlap?

I have been thinking it would be nice to have viewport functions in dojo core, but I want to resolve with what is available in dijit, and work out the best plan for both core and dijit -- maybe the dijit viewport functions could be converted to call the core functions, if we moved them into core along with this patch?

comment:3 Changed 13 years ago by bill

James - see #7028 mentioned above. The viewport functions are scheduled to be moved to core, with back-compat stubs.

comment:4 Changed 13 years ago by dante

Milestone: tbdfuture
Owner: changed from anonymous to dante
Status: newassigned

i'm inclined to agree that when we move the dijit._base stuff into dojo, we provide proper namespacing for additional viewport and screen manipulation code. did we ever decide WHERE #7028 would make the code end up living? dojo.browser? dojo.viewport?

(as per style guides it would be dojo.viewport.get() == dijit.getViewport, over dojo.viewport.getViewport, etc)

comment:5 Changed 13 years ago by ole

+1 for dojo.viewport.set(w,h) and dojo.viewport.get().

comment:6 Changed 13 years ago by cb1kenobi

This patch suffers from the same problem that dijit.getViewport() does: in Opera 9.5 (mac), dojo.body().clientHeight returns the height of the entire page, not the viewable area. Use _window.innerHeight to get the viewable height in Opera 9.5.

comment:7 Changed 13 years ago by dante


comment:8 Changed 13 years ago by bill

FYI, fixed getViewport() recently, in [15845], to work on the latest opera (9.6).

comment:9 Changed 13 years ago by ole

There's something strange going on with the method. For example I'll pass the current width of the browser, which is 1680 and it will resize the browser to a width of 1436. Here's the exact code I'll run:

	console.log("innerHeight: " + _window.innerHeight);

	console.log("adjustedWindowHeight: " + adjustedWindowHeight);
	console.log("width: " + width);
	console.log("_window.outerHeight: " + _window.outerHeight);
	console.log("_window.outerWidth: " + _window.outerWidth);

	console.log("dojo.browser.getViewport().h: " + dojo.browser.getViewport().h);
	console.log("dojo.browser.getViewport().w: " + dojo.browser.getViewport().w);
	_window.resizeTo(width, adjustedWindowHeight);

Here are the logging results:

innerHeight: 832
adjustedWindowHeight: 938
width: 1680
_window.outerHeight: 938
_window.outerWidth: 1680
dojo.browser.getViewport().h: 832
dojo.browser.getViewport().w: 1680

So with this example the browser is just being told to resize to whatever it's current dimensions are. In other words there should be no change in the window's size.

However the width changes. If I hit refresh again we can see what the current window width is, prior to getting called again. Now the logging results look like this:

Firebug's log limit has been reached. %S entries not shown.		Preferences	 
innerHeight: 824
adjustedWindowHeight: 930
width: 1436
_window.outerHeight: 930
_window.outerWidth: 1436
dojo.browser.getViewport().h: 824
dojo.browser.getViewport().w: 1436

So the firefox's width has changed to 1436. This seems to be taken from firefox's size history, if there is such a thing. I had the browser at this width, prior maximizing it.

Also if I hit refresh again, the browser does not keep shrinking, so it appears to be an issue only when the browser is maximized.

I'm hoping that a quick workaround for this is to just not resize if the parameters passes to resizeTo() are the same as the browsers current outerHeight and outerWidth.

comment:10 Changed 13 years ago by ole

OK - This appears to fix the problem:

if (width != _window.outerWidth && adjustedWindowHeight != _window.outerHeight)
		_window.resizeTo(width, adjustedWindowHeight);

Another thing that might cause strange results for people doing testing is that if firebug is open, it takes up viewport real estate, making the viewport appear smaller. Making firebug bigger, makes the viewport smaller, and vice versa. So if firebug is open (In the same window), the calculated value for adjustedWindowHeight is different than when firebug is not open.

comment:11 Changed 13 years ago by ole

Tweaked the if statement a little. Notice the
instead of &&.
if (width != _window.outerWidth
adjustedWindowHeight != _window.outerHeight)

comment:12 Changed 13 years ago by ole

Ooops - Looks like the wiki parser ate the "or" symbol. I'll put the correct code in a code block:

if (width != _window.outerWidth || adjustedWindowHeight != _window.outerHeight)

comment:13 Changed 13 years ago by dante

@ole - this doesn't work at all in IE, they don't support .outerHeight - I've come up with a way to calculate the outerheight by attempting to resize the viewport and calculating the expected versus calculated inner viewport, but that causes a flashing. Also, there is a discrepency if attempting to set the viewport from a calculated viewport object. in FF, the viewport doesn't include scrollbars, but resizeTo accounts for them (causing every subsequent attempt to size back to the same size to shrink by 15px or so)

comment:14 Changed 13 years ago by ole

I wonder if something simpler like dojo.browser.maximize() would make more sense.

dojo.browser.maximize = function()

In this case the developer would just test the viewport size, and if it's too small maximize the viewport. That will still cause flashing in some cases, but it seems like the best "Developer Tool" that can be provided, since there's no guarantee that width and height arguments can be supported by the users screen.

I managed to adjust for the scrollbar shrinking like this:

var adjustedWindowHeight = height + browserToolbarHeight;
var adjustedWindowWith = width + dojo.browser.getVerticalScrollbarWidth();


dojo.browser.getVerticalScrollbarWidth = function()
	return - dojo.browser.getViewport().w;

But attempting to set the viewport size can still cause flashing, etc. like you are saying, when either the width and height are larger than what the screen supports. I tried compensating for this by using the screen object, but the screen object does not take into account panel width's etc. in KDE, so the screen object reports an area that's bigger than what the browser is allowed to use...

comment:15 Changed 12 years ago by dante

Resolution: wontfix
Status: assignedclosed

dojo.window.viewport is moved, and lacking a good clean solution for setting viewport I'm closing this as wontfix. Perhaps a dojox module, but the usefulness is slightly limited here.

Note: See TracTickets for help on using tickets.