Bookmark Properties Window opens "full size"

[B00ze64]

Good day.

While I do not plan to use the bookmark sidebar at all (all I need is the "BSP2 Path" menu entry you've added to the bookmarks right-click menu,) I did play with the sidebar, and noticed that when I right-click and pick Properties, a full-sized window opens, then resizes itself to a tiny window and goes and places itself in the top-left corner of the screen. This is quite annoying! It flashes a lot and does not position itself near the mouse or in center of browser/screen. I tried "Remember window sizes" but that just made it worse (the window STILL opens to the same size as the whole browser, but now it resizes itself even smaller, too small for the text inside, Lol.) Some work is needed in this area ;-)

I'd be happy if you made a simpler extension that ONLY added the PATH menu entry and nothing else. By the way, why the long menu entry name "BSP2 Path to bookmark item?" A simple "Bookmark Path" would be more than sufficient and would look nicer. I'd edit the extension to fix this for my own use, in fact I did, but this stupid "extensions must be signed" thing is in the way).

Thank you.
Best Regards,

[aaFn]

Hello @B00ze64, indeed there is here a combination of bugs and strange choices by Firefox, so this is the only workaround I could find :-(

• First, panels and popups are just aliases, and when creating a new window for the property, top and left parameters for positioning it are ignored by FF. Cf. https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/windows/create
• Then, there is a workaround for popups which is to create the window (default position decided by FF), and update it to move it, cf https://bugzilla.mozilla.org/show_bug.cgi?id=1271047
• Also, there is a bug under Linux of new window contents not being painted when it is created, and so an update to its size is necessary to force painting :-( . Cf. https://bugzilla.mozilla.org/show_bug.cgi?id=1408446

All that then imposes to:

1. create the new window on a default position, with a tiny size to try to make it as less conspicuous and fast to draw as possible
2. then update it to its right size and proper position

It appears that during step 1), FF is now additionally creating the window big and then changes its size, generating one more flash .. it was not doing that in the past to my knowledge. This is a behavior that the add-on cannot master, sorry .. FF (bad) choice which I do not see how to mitigate ... :-(

On the size being insufficient when you click on "Remember window sizes" option, just resize the window and then upon close, it will remember its new size, and next time it will have that bigger size.

---

On the BSP2 menu entry, ok, I will shorten it, good suggestion, thank you.

[B00ze64]

Hi there.

Well, I'm not 100% sure the window that opens is BIG, but I can sure see it begin to paint, and it's not tiny. Why not leave it where it is? Make it the right size to begin with, and let FF open it where-ever; the top-left corner of the screen is not a great choice to move it to, it might be better if we let FF position it. Then resize it by 1 pixel for Linux. I didn't know there were so many bugs; I miss XUL lol, everything used to LOOK native, now everything looks different.

For the PATH menu, you could say "Path (by BSP)" if you wish to advertise the origin of the extra-useful menu item ;-) I don't think we need the "2" there, there is no longer a BSP-ONE. I used to use the other two extensions by Alice, Show Parent and Go To Parent, I never really use the sidebar except for History (sometimes.)

Thank you.
Best Regards,

[aaFn]

Hello @B00ze64, I shortened the menu to "Bookmark path" as per your suggestion, that will be in 2.0.79. The origin (BSP2 ..) is shown by star icon at front of it, so anyway this is redundant to mention BSP ... 😀

On the XUL topic, yes I also miss it, the WebExtension API is very poor for us, and make things difficult .. but let's hope these are youth problems and will disappear, the intent is good since XUL was too open and compromising on security.

On property window position, this was a past requirement from users that it opens at its last position. And I can undestand it, this is also how that behaves on the native sidebar, and it corresponds to a more or less conscious user behavior to arrange windows on the screen for order/visibility, or for practicality = remembering and reopening at same previous place is a natural and good practice.
So for now, we have to bear with that FF bug and workaround. At least, making the window small at first makes it less conspicuous, I just retested to see, if I use a bigger size at start (or no size at all => default), the effect is much more visible :-(
Leaving it at top could be an option for the user to activate I guess .. however that wouldn't remove the first "flash" of it being painted at a default size first as I can see. So not sure this is worth the coding effort.

[B00ze64]

Hi @aaFn.

But for me the Bookmark Properties does not remember Size or Position, UNLESS I make it really too big. First it always goes to the top-left corner of the screen, even when I make it big enough so that it remembers its size. If I make it just a LITTLE bit bigger than its default size, it just keeps getting smaller and smaller; this is what happens:

Initially it opens like this:

Then I close it open it again:

Close and open again:

Again:

Only if I make it big enough THEN it remembers SIZE, but not POSITION:

Thank you.
Best Regards,

[aaFn]

Mhh, something strange , all is working fine here, whether Windows 7 (I see this is your OS), or Windows 10 or Linux.

What you show is a bug (or a change in FF behavior, it was not there before, but anyway that was making things wrong) which was corrected as of 2.0.70, see #123.

Can you verify which version of BSP2 you have ? (hover your mouse on the yellow star icon in the toolbar, or over the magnifying glass of the search box in the sidebar, you should see 2.0.78).
And do you have any zoom factor active, different from 1 / 100% ?

Last, which version of Firefox do you have ? (current one is 77.0.1)

[B00ze64]

Good day,

Well, I can no longer reproduce 1/2 of the issue. I recently updated LOCALCDN and updated the corresponding rules in uMatrix, that might be it? I had assumed WebExtensions were immune to this kind of problem so I had not tested in a virgin profile, which I did now, and could not reproduce the shrinking window. Tried again in my test profile (the one I'd been using) and I also cannot reproduce. And the window no longer opens real big either, it barely flashes now as it moves into position!

So now the window no longer shrinks. I also found out why it does not remember its position -> user_pref("privacy.resistFingerprinting", true); Funny how stuff is constantly affecting addOns (priviledged pages) where it should not. So your window position code is breaking when Resist Fingerprinting is enabled.

EDIT: Oops, sorry, I have the latest of everything ;-)

Best Regards,

[aaFn]

Ok, thank you, I think you are hitting this https://bugzilla.mozilla.org/show_bug.cgi?id=1330882 when user_pref("privacy.resistFingerprinting", true);

I am not sure I understand the reasoning behind fingerprinting users with windows sizes (that seems odd and too random to me to be a safe way to fingerprint), but anyway this is one of the things this setting does, it changes windows sizes by rounding, and it seems to not count sizes the same way as the BSP2 code for getting current window size, hence an effect of decreasing (or increasing if rounding up) window sizes from one open to another ... :-(

Also, maybe a hit of https://bugzilla.mozilla.org/show_bug.cgi?id=1369357 if you were using zoom in your profile.

I guess users using that setting should be ready to see plenty of odd things on look and feel (fonts, sizes . etc ..) as the setting overrides plenty of the standard behavior, see https://www.ghacks.net/2018/03/01/a-history-of-fingerprinting-protection-in-firefox/

[B00ze64]

Hi aaFn.

Yeah, we expect things to break on Web Pages, but we expect addOns to be able to get the size of the window correctly, there's no point in resisting fingerprinting from addOns lol. Bug 1330882 is for the whole browser window, once that's opened it should no longer be a factor. And I do not use Zoom so it probably isn't bug 1369357. You code remembers the Y position of the properties window correctly, but when resistFingerprinting is enabled the properties always open at the left edge of the browser...

Best Regards,

[aaFn]

Correct, the add-on gets the size and position, but FF seems to resize it by rounding based on a different size than the one captured (e.g. the add-on gets the internal window size and FF resizes based on the external window size .. or something like that), so this is what is creating that effect of decreasing sizes across each open.
And of course, FF changes the position to what it wants (plus the problem of big window at start it seems), so ignores what the add-on specifies.

[B00ze64]

Hi aaFn.

I tested again just now and with Resist Fingerprinting the window once again gets smaller and smaller. Strange, that had stopped happening the other night, it just would not remember its X position but everything else was working; tonight it's back to shrinking. There has to be a better way of doing this; or you might want to open a bug on bugzilla - one more for the Mozilla folks to ignore for 17 years lol.

Best Regards,

[B00ze64]

https://bugzilla.mozilla.org/show_bug.cgi?id=1649050

[aaFn]

Thanks, the comments are good, let's see what they suggest as workaround at least, I suspect they may not easily distinguish what is an andd-on and what is javascript embedded in a page ..

[B00ze64]

Hi there, been away for a while. Looked at our Bug 1649050 today; the Mozilla testing person managed to reproduce the window opening misbehaviour on MAC even when resistFingerprinting is disabled; she says:

Please note though that on Mac, if "privacy.resistFingerprinting" is set to "false", the Properties Window for Bookmark Search Plus 2 still changes size and position, but it's the other way around, the window increases in size until it's full-screen.

You could have a look at DownThemAll, I'm sure the code is huge but somewhere in there, the Author manages to open a window correctly even with resistFingerprinting turned on.

Best Regards,

[aaFn]

Hello @B00ze64, I had to change that code in 2.0.80 anyway, because there is an inconsistency in FF API which is making some calls sensitive to DPI and others not.
I believe this is the problem on Mac that the Mozilla person observed, although I could never reproduce it on my side. Probably because I have no Mac so I have to rely on emulation .. and so I do not have a full retina screen with internal zoom factor.

Anyway, I believe the new code should fix the Mac problem. And maybe also the sensitivity to resistFingerprinting ?? Could you try on your side and let me know ?

Thanks, aaFn.