Resizing the browser window does not take size of taskbars and DPI into account

While working on legacy/trac#8478 (closed) I realized that the proper resizing might still fail due to existing task bars or due to resizing the task bars after an OS update (happened in my case).

added component::applications/tor browser in Legacy / Trac owner::mikeperry in Legacy / Trac priority::high in Legacy / Trac resolution::invalid in Legacy / Trac status::closed in Legacy / Trac tbb-fingerprinting in Legacy / Trac tbb-firefox-patch in Legacy / Trac tbb-helpdesk-frequent in Legacy / Trac type::defect in Legacy / Trac labels

This might need a new approach to resize the browser window. Now, the screen width and height are used as a starting point but it would be more accurate to take the maximal available width and height for the browser window instead. My first idea to use window.maximize() during onLoad() failed.

Trac:
Cc: N/A to intrigeri@boum.org

See: https://trac.torproject.org/projects/tor/ticket/10441#no5 for an instance of this problem on a Windows machine. Note, though, that the taskbar is not the only problem. Even if it is hidden, the screen is not properly resized due to the changed DPI value.

Trac:
Summary: Resizing the browser window does not take size of taskbars into account to Resizing the browser window does not take size of taskbars and DPI into account

Trac:
Username: joebt

Trac:
Username: joebt

Sorry, typed details of issues & various scenarios (w/ different results), where Title bar & sizing buttons are hidden. When went to add attachment & my comment disappeared & wasn't in Firefox memory. On most sites / forums, what I've typed WOULD be in stored pages.

Some of the details are on attachment.

Trac:
Username: joebt

Replying to joebt:

Some of the details are on attachment.

I have seen these symptoms as well. I think a large taskbar was the problem in this case on my testing machine. Could that be an issue in your case as well? One thing I am wondering is why the NoScript and HTTPS Everywhere buttons are not on the toolbar but on the add-on bar at the bottom of the window. Did you configure that this way or does it happen even if you download a fresh TBB?

No, don't think the task bar is as large as most users (in Vista). It's nearly identical height as the addon bar (in screen shot).

Besides, if dozens of other apps don't have a problem - w/ ANY settings (incl. Tb, Fx), then TBB 3.5 should be able to handle it. It began & appears only in TBB v3.5.

If I start earlier TBB versions, they don't do this. That's fairly conclusive it's TBB's problem, __not __Vista desktop / DPI settings, etc. That may be a detail that "disappeared" along w/ my original comments. That'll learn me for not copying comments before adding attachments or for not using an extension that saves comments.

Re: Icons moved to addon bar. I opened the customization window, dragged icons from Nav bar to the window, then to addon bar. Could also put them on R side of addon bar. I put TBB extension icons in same place as identical ones in Fx. More consistent & don't have to "search." I tend to forget icons on Nav bar. Otherwise, doesn't matter.

Trac:
Username: joebt

joebt: Did something change with the latest TBB versions (3.5.2/3.5.2.1). They contain two fixes that might at least help to figure out what is going on on your computer.

Would it possible to merge the following screen-prefs.patch? It allows users to choose a static (inner) window size via extensions.torbutton.window.inner{Width,Height}.

Use cases:

• Work around this bug!
• Join the largest possible anonymity set, which appears to be 1000x600: https://trac.torproject.org/projects/tor/ticket/10095#comment:41
• Easier testing

Trac:
screen-prefs.patch

Set a static size with extensions.torbutton.window.inner{Width,Height}

Trac:
tb.diff.txt

Compute inner size properly with taskabars, different DPI or something else

Attached patch that fixes any problems with DPI or non standard taskbar. It relies on using window.screen.avail{Width,Height}. Tested with XP, where it really returns available sizes.

Is this patch up for review? Then please adjust the ticket status to needs_review otherwise we might overlook it. That said, the tricky part here is to make the resizing not visible for the user. I have not tested your patch yet, but does it work this way?

Great. Is there a way I can (easily) test the patch? Exactly how should the patch be applied in ? TB 3.5.3?

Trac:
Username: joebt

That said, the tricky part here is to make the resizing not visible for the user. I have not tested your patch yet, but does it work this way? It just replaces call of win.resizeBy() with call of torbutton_resize_window(), actually. So no order of resizing changed, and it shouldn't be visible for the user.

Trac:
Status: new to needs_review

Great. Is there a way I can (easily) test the patch? Exactly how should the patch be applied in ? TB 3.5.3? You need to patch torbutton.js file inside of torbutton@torproject.org.xpi

Someone could to patch file and place ready to use xpi file so test was easy.

There are 2 files you attached. Do both need to be added to torbutton.js?

Trac:
Username: joebt

Replying to joebt:

There are 2 files you attached. Do both need to be added to torbutton.js?

It's two different persons, with two different approach to fix bug. They used multi-user account cypherpunks. I'm third cypherpunk.

Trac:
Keywords: N/A deleted, tbb-fingerprinting, GeorgKoppen201403R added

mikeperry, intrigeri: I have pushed bug_9268test to my user repo. Could you test the proposed patch? IIRC you had some machines that were affected by this bug. I am curious if the patch fixes your issues.

Trac:
Keywords: N/A deleted, MikePerry201403R added

Just found platform case where window.outerHeight not counts some graphical elements, actual height is greater than returned values. Epic. Browser have no control of that element but returns too optimistic window.screen.availHeight. Actually it wasn't problem for that case in result, with double resizeBy and rounded values, but it's lack of Firefox that can't be fixed either. No doubt about existence of cases that broken for using with window.screen.availHeight too. You can't do -51 or something as you can't know what elements yet unknown. This browser (Firefox) is full of brokenness.

Trac:
Status: needs_review to needs_revision

Attached idea that should to fix any problem in general. Not tested at all. What do you think?

Trac:
tb.idea.diff

Idea

Oh man, patches by 3 or 4 different cypherpunks and a branch by gk. If this is Sparta, which one of you is the real Spartacus? Oh wait, he wasn't even from Sparta. Now I'm really confused.

I think tb.idea.diff smells like bobnomnom's work. I will try that one first. Plus I really love that comment on the while(true) loop. What could possibly go wrong, right?

Trac:
torbutton-1.6.8.0pre1.xpi

Fix with tb.idea.diff (built from mikeperry/bug9268)

That attached XPI works on my Mac. I finally have a 200x100 multiple for a resolution. Anyone want to test on another platform and/or see if it does any janky multiple resizing (or hangs) due to that crazy while loop?

Tested on Windows and Whonix with stable TBB.

Both were 1000x600

After installing torbutton-1.6.8.0pre1.xpi​

Still 1000x600

Trac:
tb.resize.txt

Resize window till everything rounded and fits.

What could possibly go wrong, right? Fixed that. Attached tb.resize.txt with "Resize window till everything rounded and fits." and some limits.

It's still not perfect fix. Note about limits of this approach: it will work only if values resizeBy() limited (at least first time) by platform, or window.screen.avail{Width,Height} is compatibly with window.outer{Width,Height} (or just reported correctly).

For Windows(tm) browser reports correct window.screen.avail{Width,Height} and window.outer{Width,Height} with any DPI settings and so on. So even if no window size limits for them in next ESR, it still should to work properly.

For platforms without window size limits and randomish window.outer{Width,Height} with window.screen.avail{Width,Height}, sizes should be rounded anyway, but window can be out of screen space (like in legacy/trac#11319 (closed)). Anybody knows such platforms?

Useless loop. win.inner{size} returns as requested size, even if platform didn't planned to resize to those size. No difference with patch without loop. sad.

Need to patch resizeBy code so it limited size passed to platform by window.screen.avail{Width,Height} values. Then tb.resize.txt can be for any platfrom properly.

Or to fix code for platforms that report wrong window size.

Attached kludge that will fix height for platform with incorrect outerHeight, but will reduce maxHeight even if outerHeight was correct. Any ideas? Is it worth way?

Trac:
tb.kludge.diff

Kludge

Trac:
tb.kludge2.diff

Kludge2

Attached kludge2, it should to reduce maxHeight only if window.outerHeight == window.innerHeight, which is not true for OS Windows. Questions about usage of mozInnerScreenY remains. What do you think?

Trac:
tb.kludge3.diff

Kludge3