Opened 6 years ago

Closed 5 years ago

#9268 closed defect (invalid)

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

Reported by: gk Owned by: mikeperry
Priority: High Milestone:
Component: Applications/Tor Browser Version:
Severity: Keywords: tbb-fingerprinting, tbb-helpdesk-frequent, tbb-firefox-patch
Cc: intrigeri@…, mcs Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

While working on #8478 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).

Child Tickets

Attachments (13)

TBB 3.5 title bar sometimes hidden.jpg (163.7 KB) - added by joebt 6 years ago.
screen-prefs.patch (963 bytes) - added by cypherpunks 5 years ago.
Set a static size with extensions.torbutton.window.inner{Width,Height}
tb.diff.txt (4.6 KB) - added by cypherpunks 5 years ago.
Compute inner size properly with taskabars, different DPI or something else
tb.idea.diff (5.1 KB) - added by cypherpunks 5 years ago.
Idea
torbutton-1.6.8.0pre1.xpi (1.1 MB) - added by mikeperry 5 years ago.
Fix with tb.idea.diff (built from mikeperry/bug9268)
tb.resize.txt (5.6 KB) - added by cypherpunks 5 years ago.
Resize window till everything rounded and fits.
tb.kludge.diff (4.9 KB) - added by cypherpunks 5 years ago.
Kludge
tb.kludge2.diff (4.9 KB) - added by cypherpunks 5 years ago.
Kludge2
tb.kludge3.diff (5.0 KB) - added by cypherpunks 5 years ago.
Kludge3
tb.kludgefinal.diff (5.0 KB) - added by cypherpunks 5 years ago.
Final kludge
torbutton-1.6.7.0.xpi (1.1 MB) - added by gk 5 years ago.
the final kludge
torbutton-1.6.10.0.xpi (1.1 MB) - added by gk 5 years ago.
the final stopgap
torbutton-1.6.11.1.xpi (1.1 MB) - added by ZcbCkyj5 5 years ago.

Change History (108)

comment:1 Changed 6 years ago by gk

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.

comment:2 Changed 6 years ago by intrigeri

Cc: intrigeri@… added

comment:3 Changed 6 years ago by gk

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

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.

Changed 6 years ago by joebt

comment:4 Changed 6 years ago by 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.

Last edited 6 years ago by joebt (previous) (diff)

comment:5 in reply to:  4 Changed 6 years ago by gk

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?

comment:6 Changed 6 years ago by joebt

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.

comment:7 Changed 5 years ago by gk

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.

comment:8 Changed 5 years ago by cypherpunks

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:

Last edited 5 years ago by cypherpunks (previous) (diff)

Changed 5 years ago by cypherpunks

Attachment: screen-prefs.patch added

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

Changed 5 years ago by cypherpunks

Attachment: tb.diff.txt added

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

comment:9 Changed 5 years ago by cypherpunks

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.

comment:10 Changed 5 years ago by gk

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?

comment:11 Changed 5 years ago by joebt

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

comment:12 Changed 5 years ago by cypherpunks

Status: newneeds_review

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.

comment:13 Changed 5 years ago by cypherpunks

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.

comment:14 Changed 5 years ago by joebt

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

comment:15 in reply to:  14 Changed 5 years ago by cypherpunks

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.

comment:16 Changed 5 years ago by gk

Keywords: tbb-fingerprinting GeorgKoppen201403R added

comment:17 Changed 5 years ago by gk

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.

comment:18 Changed 5 years ago by mikeperry

Keywords: MikePerry201403R added

comment:19 Changed 5 years ago by cypherpunks

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.

comment:20 Changed 5 years ago by cypherpunks

Status: needs_reviewneeds_revision

comment:21 Changed 5 years ago by cypherpunks

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

Changed 5 years ago by cypherpunks

Attachment: tb.idea.diff added

Idea

comment:22 Changed 5 years ago by mikeperry

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?

Changed 5 years ago by mikeperry

Attachment: torbutton-1.6.8.0pre1.xpi added

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

comment:23 Changed 5 years ago by mikeperry

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?

comment:24 Changed 5 years ago by cypherpunks

Tested on Windows and Whonix with stable TBB.

Both were 1000x600

After installing torbutton-1.6.8.0pre1.xpi​

Still 1000x600

Changed 5 years ago by cypherpunks

Attachment: tb.resize.txt added

Resize window till everything rounded and fits.

comment:25 Changed 5 years ago by cypherpunks

What could possibly go wrong, right?

Fixed that. Attached tb.resize.txt with "Resize window till everything rounded and fits." and some limits.

comment:26 Changed 5 years ago by cypherpunks

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 #11319). Anybody knows such platforms?

Last edited 5 years ago by cypherpunks (previous) (diff)

comment:27 Changed 5 years ago by cypherpunks

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.

comment:28 Changed 5 years ago by cypherpunks

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.

comment:29 Changed 5 years ago by cypherpunks

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

comment:30 Changed 5 years ago by cypherpunks

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?

Changed 5 years ago by cypherpunks

Attachment: tb.kludge.diff added

Kludge

Changed 5 years ago by cypherpunks

Attachment: tb.kludge2.diff added

Kludge2

comment:31 Changed 5 years ago by cypherpunks

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?

Changed 5 years ago by cypherpunks

Attachment: tb.kludge3.diff added

Kludge3

comment:32 Changed 5 years ago by cypherpunks

Attached kludge3, yet more kludges.

Changed 5 years ago by cypherpunks

Attachment: tb.kludgefinal.diff added

Final kludge

comment:33 Changed 5 years ago by cypherpunks

Final kludge attached.

comment:34 Changed 5 years ago by gk

Pushed bug_9268_finalkludge with the latest and greatest code to my torbutton repo for testing + attached the resulting xpi.

cypherpunks: The code looks good so far, thanks. I am not really convinced yet that we need the kludge part. For instance, in which cases should the outerHeight and the innerHeight be equal? You hint at maximized windows. But even there you have browser chrome (toolbars etc.). Maybe you mean fullscreen mode? But even then Tor Browser is never starting in fullscreen mode nor with missing browser chrome. At least I can currently not think of a use-case in which it would do that. And I don't understand the no window case either. If we have no window then there are window properties either. Which in turn does not work with all the calculations we do. So: What's that fancy kludge thingy for? Maybe it has to do with the "randomish outer{Width,Height}"? What do you mean with that? Is there something in the Mozilla code that makes you believe there is such kind of randomness?

Changed 5 years ago by gk

Attachment: torbutton-1.6.7.0.xpi added

the final kludge

comment:35 Changed 5 years ago by cypherpunks

For instance, in which cases should the outerHeight and the innerHeight be equal? You hint at maximized windows. But even there you have browser chrome (toolbars etc.). Maybe you mean fullscreen mode? But even then Tor Browser is never starting in fullscreen mode nor with missing browser chrome. At least I can currently not think of a use-case in which it would do that.

The outerHeight and the innerHeight be equal if Firefox using gtk widget, for maximized and normal windowState.

And I don't understand the no window case either. If we have no window then there are window properties either.

It happens for first call of torbutton_resize_window(win). Browser reports both window.mozInnerScreenY and window.screenY are zero.

What's that fancy kludge thingy for?

For gnome, I believe.

Is there something in the Mozilla code that makes you believe there is such kind of randomness?

It doesn't adds height of title bar to window.outerHeight. It's probably lack of usage gtk api, however?

comment:36 Changed 5 years ago by cypherpunks

Btw, I think kludge should to check negative value of delta_fix:

if (delta_fix <= 0)

instead of

if (delta_fix == 0)

And as every kludge, after:

delta_fix = Math.floor(diff_height / 2);

Rounding or proper placement of window can to fail in result if user changed browser's toolbars in some way, removed, resized, etc.

comment:37 in reply to:  35 Changed 5 years ago by gk

Replying to cypherpunks:

For instance, in which cases should the outerHeight and the innerHeight be equal? You hint at maximized windows. But even there you have browser chrome (toolbars etc.). Maybe you mean fullscreen mode? But even then Tor Browser is never starting in fullscreen mode nor with missing browser chrome. At least I can currently not think of a use-case in which it would do that.

The outerHeight and the innerHeight be equal if Firefox using gtk widget, for maximized and normal windowState.

How so? Even if no titlebar is added as you claim (a thing I could not reproduce) there is still at least the location bar rendered giving you a different outerHeight.

comment:38 Changed 5 years ago by cypherpunks

How so? Even if no titlebar is added as you claim (a thing I could not reproduce) there is still at least the location bar rendered giving you a different outerHeight.

Difference of outerHeight and innerHeight is only about titlebar. For OS Windows this difference includes borders yet (for Win7 where no menu bar by default, window.mozInnerScreenY == window.screenY, but inner and outer sizes are different because bottom border only).
I guess it depends shell interface used for gnome, but I believe next after OS Windows userbase affected by this "outerHeight == innerHeight" bug (or feature).
It could be sound wrong with comparing to documents from mozilla site, and confused with all mess of menu and title bar, but it's result of practical research.

Last edited 5 years ago by cypherpunks (previous) (diff)

comment:39 Changed 5 years ago by cypherpunks

How to test this bug faster using any Firefox (vanilla includes).

  1. Open Browser Console (Ctrl+Shift+J)
  2. Type there: window.outerHeight - window.innerHeight
  3. Press Enter.
  4. Report result and DE (or WM, or something) here.

comment:40 Changed 5 years ago by gk

Without any toolbar I get 6. If I add the menubar I get 38 if I add to that the location bar I get 38 and if I additionally add the bookmark bar I get 38 as well. This is on Win 7 with TBB 3.5.3. So far, so good. BUT: For the issue at hand it is not important what the values/differences in the browser console are compared to those we have when checking for outerHeight == innerHeight, right? So let's see how the values behave when we look at the log in torbutton_resize_window() which is the place where the comparison matters. On the same machine, the first time that function is called I get without any toolbar 56; with the addition of the location bar I get 91; if I add to that the menubar I get 119 and if I add to that the bookmark bar I get 143. Thus, the toolbars matter here! (and you can observe similar results in later calls to this function). And, as we always ship the browser with the location bar enabled I cannot see how outerHeight can be equal to innerHeight (even if the titlebar were not visible) and why we therefore need the kludge.

comment:41 in reply to:  40 ; Changed 5 years ago by cypherpunks

Replying to gk:

Without any toolbar I get 6. If I add the menubar I get 38 if I add to that the location bar I get 38 and if I additionally add the bookmark bar I get 38 as well. This is on Win 7 with TBB 3.5.3. So far, so good. BUT: For the issue at hand it is not important what the values/differences in the browser console are compared to those we have when checking for outerHeight == innerHeight, right? So let's see how the values behave when we look at the log in torbutton_resize_window() which is the place where the comparison matters. On the same machine, the first time that function is called I get without any toolbar 56; with the addition of the location bar I get 91; if I add to that the menubar I get 119 and if I add to that the bookmark bar I get 143. Thus, the toolbars matter here! (and you can observe similar results in later calls to this function). And, as we always ship the browser with the location bar enabled I cannot see how outerHeight can be equal to innerHeight (even if the titlebar were not visible) and why we therefore need the kludge.

Are you sure do you counts window.innerHeight, and not win.innerHeight?

comment:42 Changed 5 years ago by cypherpunks

I don't know why your Win7 so different than I had mine. For win7 and winxp I had, window.outerHeight - window.innerHeight is about titlebar + borders only, if menu bar and title bar displayed.

comment:43 Changed 5 years ago by cypherpunks

Ok, I'll give up with this browser. Too much broken for me. You can to do anything you want with patches.

comment:44 in reply to:  41 Changed 5 years ago by gk

Replying to cypherpunks:

Replying to gk:
Are you sure do you counts window.innerHeight, and not win.innerHeight?

Ah, yes! That was my mistake. Now I see your point, nice work! Although I still don't know why the values from the browser console are different. Good. So, I'll prepare a proper branch for merging tomorrow (incl. replacing

if (delta_fix == 0)

with

if (delta_fix <= 0)

).

comment:45 Changed 5 years ago by cypherpunks

Although I still don't know why the values from the browser console are different.

They not different for me, if testing OS Windows. Using:

    torbutton_log(5, window.outerHeight + " " +
                     window.innerHeight + " " +
                     window.mozInnerScreenY + " " +
                     window.screenY + " " +
                     diff_height + " " +
                     diff_width + " " +
                     delta_fix);

And difference of window.outerHeight and window.innerHeight never changes. Difference the same for every call, as from console.

Another platforms have different sizes. Just found case where window.innerHeight is zero always.
Kludge was planned for non OS Windows, but seems like covers only some specific unity gnome case and not all non OS Windows cases.

comment:46 Changed 5 years ago by cypherpunks

Ok. I found that console window is window too, suddenly, and values can be reported for console window and not for main window.
So proper result can be made only for logging during resizing by Torbutton.

comment:47 Changed 5 years ago by cypherpunks

but seems like covers only some specific unity gnome case and not all non OS Windows cases.

Not sure again. Need more reports about used WM where TBB reports different sizes for outer and inner size.

comment:48 Changed 5 years ago by gk

Okay, (hopefully) final question(s): Why

delta_fix++

? Why should incrementing it be necessary at all? And why is incrementing it by 1 enough?

comment:49 in reply to:  48 Changed 5 years ago by cypherpunks

Why should incrementing it be necessary at all? And why is incrementing it by 1 enough?

Incrementing need because size of separator in between of menu and title bars.(window.mozInnerScreenY is about coordinates of this separator)
I don't know if separator affected by DPI (zooming or anything yet), actually. But 1 pixel was verified experimentally for two different WM. (this 1px present even for OS Windows, but this code not used there because outerHeight is correct and includes everything)

comment:50 Changed 5 years ago by cypherpunks

(this 1px present even for OS Windows, but this code not used there because outerHeight is correct and includes everything)

Add: window.mozInnerScreenY is about coordinates of top of menu bar for OS Windows, i.e. window.mozInnerScreenY - window.screenY reports size of top border + menu bar + 1px. (size of menubar from OS configuration, where it named Active Title Bar, and border size counted as (window.outerWidth - window.innerWidth)/2)
It's all no matter for OS Windows actually, just for clarity how OS Window different event from point of view of browser cross-platfrom internalies.

Last edited 5 years ago by cypherpunks (previous) (diff)

comment:51 Changed 5 years ago by cypherpunks

And maybe screenPixelsPerCSSPixel ratio need to be used for window.mozInnerScreenY?
(I was confised by code it seems, they all CSSPixels there)

comment:52 in reply to:  51 Changed 5 years ago by gk

Replying to cypherpunks:

And maybe screenPixelsPerCSSPixel ratio need to be used for window.mozInnerScreenY?
(I was confised by code it seems, they all CSSPixels there)

Yes, I am about to add that. Although I think it should not matter much at the moment as we are not working with zoom yet when we start or after "New Identity".

comment:53 Changed 5 years ago by gk

WTF! This new code is too slow it seems. :( I have at least one computer where I see the small window before it is properly resized. Let's try to optimize it then...

comment:54 Changed 5 years ago by cypherpunks

I have at least one computer where I see the small window before it is properly resized.

Smaller by width or by height?
If by height then it's about "delta_fix = Math.floor(diff_height / 2);" which can be non optimal value for try without knowing real title bar size. I don't know how to optimize it. You can to hardcode it to some values probably, but which one? Will it work for another computer? kludge invites kludges, alas.

comment:55 Changed 5 years ago by gk

The problem is probably that calling the function and calculating all the stuff three times (compared to doing that only once) is introducing enough delay on start-up that the resizing is visible. That's the fear I had in comment 10. If you have ideas on how to avoid that go for it :)

comment:56 Changed 5 years ago by cypherpunks

window.screen.availHeight and window.screen.availWidth can be fetched only once passed on function. Then to skip window.windowState (used only for logs). To reduce log level?
All outer and inner sizes need to calculate again every time.

However. "Slowness" is result of different sizes requested for resize for every call of function, I think. Delay can't be reduced in beetween initial resize and resize on MutationObserver.

You can to calculate needed titlebar size and hardcode it for test purpose. Result should be the same as before this ticket.

comment:57 Changed 5 years ago by cypherpunks

Tested with slowdown box, screen size: 1024x768, two desktop pannels top and bottom, avail size in result is 1024x706.
On initial resize (window.mozInnerScreenY - window.screenY) is zero, diff_height counted as 82, so delta_fix is 41, then max dimension for inner size counted as 1024x583, requested (rounded) 1000x500.
Resize on MutationObserver: (window.mozInnerScreenY - window.screenY) is 22, so delta_fix is 23, then max dimension for inner size is 1024x601, requested (rounded) 1000x600.

Window on initial resize is smaller by height, but no about:tor page rendered. It even visible how toolbars appended one by one. In result all resizing looks like process of creating window and not like sudden resize of window.

Is it what you observes or something else?

comment:58 in reply to:  57 Changed 5 years ago by gk

Replying to cypherpunks:

Is it what you observes or something else?

Something like that, yes. Note that this does not happen for me with the current Torbutton .xpi we ship.

comment:59 Changed 5 years ago by cypherpunks

Note that this does not happen for me with the current Torbutton .xpi we ship.

Current code can't handle case where desktop panels non standard or changed bars inside browser, current (-51) is kludge too that will work for above case only because every panel is about 30 px, and result window with 600px of inner height fits on screen. Else sizes could be non rounded or window non fitted on screen (covered partially by bottom panel, or something).
No way to fix this way, so no visible resizing and everything fitted and rounded, using patches for Torbutton. The proper way is to fix code to return correct outerHeight for every used widget, after that no kludges for Torbutton needs.

comment:60 Changed 5 years ago by cypherpunks

The proper way is to fix code to return correct outerHeight for every used widget, after that no kludges for Torbutton needs.

And even after that, visible resizing can happen for case where toolbars changed in between initial and last resisings. All depends final values and avail space.

comment:61 Changed 5 years ago by gk

I pushed another branch into my repo bug_9268_wip containing the best I can currently come up with. It turns out that availHeight and availWidth are the same on some OS/window manager configurations (see my comment in torbutton.js for more details). So, this approach is neither working for the cypherpunk patch nor for mine. Then: with the cypherpunk patch while having a different DPI, the resolution is not properly rounded (the width on my Win 7 box is always of at least one pixel). Alas, my patch is doing worse :(. To sum up: There is currently neither a general solution for problems with the taskbar nor one with non-default DPI settings we could deploy.

comment:62 Changed 5 years ago by cypherpunks

Coming back full circle then, may I reiterate my proposal from #comment:8?

Last edited 5 years ago by cypherpunks (previous) (diff)

comment:63 in reply to:  62 ; Changed 5 years ago by gk

Replying to cypherpunks:

Coming back full circle then, may I reiterate my proposal from #comment:8?

What width and height do you want to choose? 1000 x 600? What happens in case I have a netbook with a resolution of, say, 800x600? In short, I think hard-coding some value without looking at the actual size available is not the way to go here. It probably creates a lot more trouble than it solves.

comment:64 Changed 5 years ago by gk

Component: TorBrowserButtonFirefox Patch Issues
Keywords: GeorgKoppen201403R removed

Moving this to Firefox Patch Issues as I don't see how to solve this issue with an extension alone.

comment:65 in reply to:  63 Changed 5 years ago by cypherpunks

Replying to gk:

Replying to cypherpunks:

Coming back full circle then, may I reiterate my proposal from #comment:8?

What width and height do you want to choose? 1000 x 600? What happens in case I have a netbook with a resolution of, say, 800x600? In short, I think hard-coding some value without looking at the actual size available is not the way to go here.


God no, it's the user who can configure the values if necessary (but doesn't have to).

The patch does not ship default values or anything! It simply provides an override mechanism activated only by actually configuring extensions.torbutton.window.inner{Width,Height}.

E.g., on my large screen, I choose 1000x600.

And other people affected by this bug would be able to actually do something to normalize their fingerprint until this is fixed properly, which looks like it might take a while.

comment:66 Changed 5 years ago by gk

I see. This + the best patch we currently have might be a stopgap that is worth implementing given the nature of the problem. I'll think about it.

comment:67 Changed 5 years ago by mttp

Keywords: tbb-helpdesk-frequent added

comment:68 in reply to:  66 Changed 5 years ago by cypherpunks2

Replying to gk:

I see. This + the best patch we currently have might be a stopgap that is worth implementing given the nature of the problem. I'll think about it.

How are you leaning? :)

Is there any downside to #comment:8 that I've overlooked?

Last edited 5 years ago by cypherpunks2 (previous) (diff)

comment:69 Changed 5 years ago by mcs

Cc: mcs added

comment:70 Changed 5 years ago by gk

Keywords: TorBrowserTeam201406 added; MikePerry201403R removed

comment:71 Changed 5 years ago by joebt

Is it feasible to post important bugs on tor-talk, stack exchange or other, when solutions aren't found after a long time? At least, links to them & short descriptions - asking for input. This is a fingerprinting issue that was reported a yr ago.

Concept being, the more heads working on a problem, the better. Sometimes, people come up w/ general ideas for solutions, even if they don't have expertise to implement them.

For any open source project, a lot of users aren't aware of certain problems, unless they regularly follow bug reports, etc. Many products don't just advertise through one medium or on one TV channel.

comment:72 Changed 5 years ago by gk

Keywords: MikePerry201406R added
Status: needs_revisionneeds_review

bug_9268_final_stopgap_rebased in my public torbutton repo has a patch that a) allows the user to override the decisions made by Torbutton's resizing logic via two preferences if that is necessary and b) takes the size of taskbars and the DPI value into account. Attached is an .xpi for testing. There are some corner-corner cases that remain, of course...

Changed 5 years ago by gk

Attachment: torbutton-1.6.10.0.xpi added

the final stopgap

comment:73 Changed 5 years ago by gk

Keywords: TorBrowserTeam201406 removed

The stopgap landed in 8e38c9f33fbfcccfd9b4071360a976b67c340cee and should be available in the next alpha release.

comment:74 Changed 5 years ago by joebt

Tor browser is again starting w/ part of the browser toolbar and window sizing buttons off the monitor. By default, TBB starts in a partial screen mode. The only way to access the hidden window resizing buttons is to grab the bottom edge of browser window & drag it up some.

Then the top of browser screen automatically "lowers" a bit, where the resizing buttons are visible.

I'm fairly sure this is due to setting my Windows DPI to greater than default (96). For a while, it was set at system default size & there was no issue w/ starting TBB UI height. As soon as I changed the Windows DPI to > 96, the TBB opening size was once again too long.
See orig screen: https://trac.torproject.org/projects/tor/attachment/ticket/9268/TBB%203.5%20title%20bar%20sometimes%20hidden.jpg

I checked a clean install of TBB 3.6.2 in new folder (no addons, plugins) - still showed the opening screen height problem.

Note: TBB is the only app I use (out of many) that has a problem opening the correct size when the system DPI is > 96. Why is that? Vanilla Fx, nor any other prgm have this problem (large corporations or one man developed apps). Is there something inherent about TBB that doesn't handle non-standard DPI settings?

Last edited 5 years ago by joebt (previous) (diff)

comment:75 Changed 5 years ago by erinn

Keywords: tbb-firefox-patch added

comment:76 Changed 5 years ago by erinn

Component: Firefox Patch IssuesTor Browser

Changed 5 years ago by ZcbCkyj5

Attachment: torbutton-1.6.11.1.xpi added

comment:77 in reply to:  74 Changed 5 years ago by ZcbCkyj5

Replying to joebt:

Tor browser is again starting w/ part of the browser toolbar and window sizing buttons off the monitor. By default, TBB starts in a partial screen mode. The only way to access the hidden window resizing buttons is to grab the bottom edge of browser window & drag it up some.

Then the top of browser screen automatically "lowers" a bit, where the resizing buttons are visible.

I'm fairly sure this is due to setting my Windows DPI to greater than default (96). For a while, it was set at system default size & there was no issue w/ starting TBB UI height. As soon as I changed the Windows DPI to > 96, the TBB opening size was once again too long.
See orig screen: https://trac.torproject.org/projects/tor/attachment/ticket/9268/TBB%203.5%20title%20bar%20sometimes%20hidden.jpg

I checked a clean install of TBB 3.6.2 in new folder (no addons, plugins) - still showed the opening screen height problem.

This problem is fixed with the latest version of Torbutton 1.6.11.1. Download it from the ticket attachments and put it in the Tor Browser\Data\Browser\profile.default\extensions folder.

comment:78 Changed 5 years ago by joebt

OK, ZcbCkyj5 (wow, some name!)

I installed Torbutton 1.6.11.1. It fixes TBB starting up w/ the sizing buttons off the top of monitor.

But, referencing other bugs about the design of TBB starting at screen multiples of 200x100 - I don't see anything close to that. So, I'm out in the empty parking lot, alone - for every website to ID me?

Now, when it starts, I've used a screen capture app & reading the capture size.
Depending on whether the TBB "design" opening size of 200x100 is supposed to be the entire GUI, or the usable TBB browser pane (sans toolbars) - neither is even close to a 200x100 multiple.

Is the intended behavior that TBB will report a multiple of 200x100, or in addition to that, users should also see starting TBB sizes in 200x100 multiples? If the latter, it's not happening for me.

I have Windows system DPI set a bit higher - @ 110 vs. default 96 DPI. Even adjusting for that, they're still not close to 200x100 multiple.

  • The full starting TBB GUI, incl. toolbars is ~ 1170px x 1025px.
  • The usable browser pane below the toolbars (incl. the narrow borders around apps, that Windows adds) - then starting size is ~ 1170px x 930px.

There's some minor error in determining if the screen shot's selection line is exactly on the TBB screen edge. But the size isn't anywhere near a multiple of 200x100, regardless of all the possible errors I mentioned.

For the values of entire starting GUI, if 1170 is rounded to 1200, that's 6 * 200. But the value for measured screen height (1025) is way more than 6 * 100. No matter how much of a reasonable error correction is used for DPI changes, error in reported captured screen size, etc.

  • One MAIN question: When was that design spec for starting screen size multiple of 200x100 invented?

How much has changed since then as to what GUI elements are displayed by default in TBB (Firefox) vs. when that design spec was developed?

No longer have an addon bar. No longer display a menu bar by default, etc.

I don't know how all that affects the actual starting size vs. reported 200x100 multiple.

Last edited 5 years ago by joebt (previous) (diff)

comment:79 in reply to:  78 Changed 5 years ago by cypherpunks

Replying to joebt:

Is the intended behavior that TBB will report a multiple of 200x100, or in addition to that, users should also see starting TBB sizes in 200x100 multiples?

The former. What you call the reported size is the inner window content area, without toolbars or borders, and that's what's accessible to websites. (TBB is designed to hide the actual larger window and screen sizes from them.) You can test whether this inner size is correctly rounded to 200x100 multiples using e.g. https://panopticlick.eff.org/ or http://browserspy.dk/screen.php.

Last edited 5 years ago by cypherpunks (previous) (diff)

comment:80 Changed 5 years ago by joebt

Thanks.

You can test whether this inner size is correctly rounded to 200x100 multiples using...

No, those test sites don't report the TBB opening (partial) screen size as a 200x100 multiple. They never have - in over a yr of testing. Not even close. That's what I've been saying & asking about - in multiple bug reports that touch on this, on tor-talk and on Stack Exchange Tor forum.

Just now, w/ Torbutton 1.6.11.1 installed, Browser Spy initially showed my opening TBB screen "width" & "height" as 1000 & 794. Odd number for the height, but no matter how you correct it (for my system DPI being 110 vs. 96, etc.), it's not even close to 200x100 multiple. Again, it never is / has been.

  • Where (all) should I report this? If I'm one of a few Tor users that sites don't see a 200x100 multiple, then I stick out like a sore thumb.
  • Besides, what % of users actually keep a browser in partial screen that's much < full screen? All the time? In 20+ yrs, I've never seen anyone do it for general browsing. Once in a while - yes.

Interestingly, after Browser Spy site had been loaded for a bit, it later showed TBB screen size 1000x800.  Not close to 200x100 multiple.  They also report the resolution (under that test) as 96 DPI (it's 110).  Maybe TBB spoofs it at 96?

Don't know if the change from 794 to 800 is from the NoScript popup notice (bar running width of screen) that JS objects were blocked, that disappears after a few sec.

Last edited 5 years ago by joebt (previous) (diff)

comment:81 in reply to:  80 Changed 5 years ago by cypherpunks

Replying to joebt:

Just now, w/ Torbutton 1.6.11.1 installed, Browser Spy initially showed my opening TBB screen "width" & "height" as 1000 & 794.

Try this: Go to about:config, create a new integer called extensions.torbutton.window.innerHeight, set it to 700, restart the browser, and test again.

Interestingly, after Browser Spy site had been loaded for a bit, it later showed TBB screen size 1000x800.  Not close to 200x100 multiple.

1000=200*5, and 800=100*8. The multipliers don't have to be the same for width and height.

Don't know if the change from 794 to 800 is from the NoScript popup notice (bar running width of screen) that JS objects were blocked, that disappears after a few sec.

If you care about your fingerprint, you should leave NoScript (and almost everything else) in its default configuration as shipped by TBB. Blocking JavaScript, especially if done selectively, will shrink your anonymity set (= increase your fingerprint). Maybe delete your TBB installation and start over fresh with the current TBB version.

Last edited 5 years ago by cypherpunks (previous) (diff)

comment:82 Changed 5 years ago by joebt

Blocking JavaScript, especially if done selectively, will shrink your anonymity set (= increase your fingerprint)

Don't know about that. Not according to Panopticlick & other testing sites, AFAIK.

1000=200*5, and 800=100*8. The multipliers don't have to be the same for width and height.

That's not the mathematical meaning of:

Right now, we set the size of new Tor Browser windows such that their content area is a 200x100 multiple.

Mike said, "* A * multiple," not "multipleS." I took him at his word, since he's a learned person.

"* A * multiple of 200x100" - means they go together. e.g., 400x200, 1000x500.

"MultipleS of 200(W) *AND* 100(H)" means different factors can be used w/ each.

What does it matter how it was written? Because they don't ever mean the same thing.

If they can have different multipleS, then it should say "multipleS of 200 and 100 (h x w)." Which one did you mean, Mike?

Thanks for tip on about:config, but w/o testing & approval by Tor devs, I probably won't make changes w/o knowing all of the exact effects they have. I could test, but what would your example of inner height = 700 actually prove?

I only used JS because the Browser Spy (& other) test sites can't get screen size unless JS is enabled.

That brings up the other issue (which is huge). Most websites don't work fully w/o JS enabled; many not at all. Maybe a text-only blog does. So unless just going to a buddie's site to pick up your next instructions (a non-js site), many users have to enable JS or just not use most sites; certainly not fully use them.

I'm pretty sure Tor devs know this. That's why JS is enabled in TBB by default in NS. Don't get me wrong - I keep it off by default.

I'd guess there are 2 main views of Tor devs on JS in TBB:

1) If we don't enable JS, much of the net is unusable (making a browser pointless). And ? with all the other anonymity features of TBB & Tor, it's not the end of the world.

2) Much of the net is unusable w/o JS and leaving it enabled will allow users to be identified. But, we don't care, as long as we don't have to listen to whining.

Since I seriously doubt it's the latter (or anything like it), there must be a good explanation why JS is enabled.

Last edited 5 years ago by joebt (previous) (diff)

comment:83 in reply to:  82 Changed 5 years ago by cypherpunks

Replying to joebt:

1000=200*5, and 800=100*8. The multipliers don't have to be the same for width and height.

That's not the mathematical meaning of:

Right now, we set the size of new Tor Browser windows such that their content area is a 200x100 multiple.

Then that phrasing is incorrect, please file a bug. The multipliers are (and are intended to be) separate.

Thanks for tip on about:config, but w/o testing & approval by Tor devs, I probably won't make changes w/o knowing all of the exact effects they have. I could test, but what would your example of inner height = 700 actually prove?

It would narrow down the problem, but it's probably unnecessary, because:

I only used JS because the Browser Spy (& other) test sites can't get screen size unless JS is enabled.

Use a fresh TBB v3.6.3 installation, with no configuration changes, for testing your window size.

That's why JS is enabled in TBB by default in NS. Don't get me wrong - I keep it off by default.

I keep it on. Either way, the one thing you must never do is to selectively enable/disable it for only some sites, because this will identify you: https://www.torproject.org/docs/faq#TBBJavaScriptEnabled

(The only safe workflow for occasionally enabling JavaScript is this: Click the onion button, New Identity, enable JavaScript globally, go to whatever sites you want to browse, New Identity again, disable JavaScript globally again.)

Last edited 5 years ago by cypherpunks (previous) (diff)

comment:84 Changed 5 years ago by cypherpunks

Test that doesn't require JS.

comment:85 Changed 5 years ago by mikeperry

Keywords: MikePerry201408R added; MikePerry201406R removed

cypherpunks, et al: Can you please post diffs of these later Torbutton xpis for ease of review?

comment:86 Changed 5 years ago by mikeperry

Keywords: MikePerry201408R removed

Oh, that was not a patched xpi. It was a vanilla 1.6.11.1 with the workaround/stopgap.

comment:87 Changed 5 years ago by toruser314159

Hi,
I've just stumbled upon this issue while trying out EFF's Panopticlick. I'm a bit lost amid all the comments, patches, kludges and different OSs. Anyway, I'm somewhat concerned by the following data:
Screen Size and Color Depth 1615x902x24
"Within our dataset of several million visitors, only one in 2,236,864 browsers have the same fingerprint as yours."
To me this seems to be a highly serious anonymisation failure.

I'm using Torbrowser 3.6.4 on Ubuntu 14.04.

comment:88 in reply to:  87 Changed 5 years ago by gk

Replying to toruser314159:

I'm using Torbrowser 3.6.4 on Ubuntu 14.04.

This happens with a freshly downloaded vanilla Tor Browser? With a GNOME desktop? How is this set up? Do you have taskbar(s)? Did you change the DPI value?

comment:89 Changed 5 years ago by toruser314159

torbrowser is installed through a PPA: ppa:webupd8team/tor-browser
The desktop is Unity; no major modifications, but my ubuntu system is not a fresh install.
I have the normal Unity bar (launcher?) to the left, status indicators etc. at the top, below the torbrowser menu, then the tab bar, the toolbar containing the URL and the actual browser window.

I will try removing ~/.tor-browser-en and also installing from .tar.gz.
But anyway, this shouldn't happen under any circumstances.

Is there any javascript code I could run in a browser console to help isolating the root cause?

comment:90 Changed 5 years ago by toruser314159

update:
I closed torbrowser, renamed ~/.tor-browser-en, reopened torbrowser.
Now Panopticlick reports 1615x937 as my screen size.

Both values, 1615x902 (my first comment) and 1615x937, were obtained while running torbrowser maximised!

comment:91 Changed 5 years ago by toruser314159

update:
I tried a fresh install from the official .tar.gz. Still 1615x937 when maximised.
I also tried a clean 4.0-alpha1. Same result.
For now, the only workaround is using a fresh install and never maximise or change window size. (It starts with a reported size of 1000x900.)

comment:92 Changed 5 years ago by toruser314159

I've taken a screenshot and took some measurements with gimp.
1615x937 is the actual and precise window size for browser content. (However this *includes* the scroll bar at its right edge.) There doesn't seem to be any "obfuscation" or modification of the browser window size.

I'd also like to add that I'm using a dual screen setup on an nVidia display: nvidia proprietary drivers, twinview, xinerama extensions. I probably should have mentioned that earlier, but it didn't occur to me since it works so well out of the box without any major config except telling the X server the physical arrangement of the displays (which is left, which is right).

comment:93 in reply to:  91 Changed 5 years ago by gk

Replying to toruser314159:

update:
I tried a fresh install from the official .tar.gz. Still 1615x937 when maximised.
I also tried a clean 4.0-alpha1. Same result.
For now, the only workaround is using a fresh install and never maximise or change window size. (It starts with a reported size of 1000x900.)

Maximized windows are not rounded yet. That is a known limitation. See: #7255, #7256.

comment:94 Changed 5 years ago by toruser314159

Sorry for posting on this issue then, I guess I didn't search well enough.

I'm left wondering why torbrowser allows me to maximise or resize my window if it completely annihilates all anonymity. After randomly resizing (not even maximising) panopticlick immediately reported that my browser is unique among all the tested browsers.

So what is all this rounding code actually about? Only the initial window at startup?

Anyway, thanks for developing torbrowser. It's so much easier to use tor than it was some years ago!

comment:95 Changed 5 years ago by mikeperry

Resolution: invalid
Status: needs_reviewclosed

This bug has drifted. I think we should open new bugs for remaining issues with the rounding code that aren't quite a mismash of ancient issues and dead code. Current related bugs that will remain open are #14098, #14429, and #7255.

Note: See TracTickets for help on using tickets.