Open Bug 1552312 Opened 6 years ago Updated 3 years ago

Toggling Bookmarks Sidebar On/Off always causes flickering on the right side of the screen if you've selected 'Move Sidebar to Left'...

Categories

(Core :: Graphics, defect, P3)

66 Branch
defect

Tracking

()

UNCONFIRMED

People

(Reporter: postandreply, Unassigned)

Details

(Keywords: regression)

Attachments

(1 file)

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:66.0) Gecko/20100101 Firefox/66.0

Steps to reproduce:

First, open up your Bookmarks Sidebar so that it is visible. Then, if it isn't already set to be on the left side, click the drop down menu and select 'Move Sidebar to Left'. Then spam or just press a few times the shortcut to toggle Bookmarks Sidebar on/off. I used CTRL + B (which sucks because I want to use a custom F2 hotkey).

Actual results:

You will see flickering on the right side of the browser window. This is because this Firefox 66.0.5 loads the Sidebar on the right momentarily and then vanishes before it loads on the left, like it is supposed to.

Expected results:

Well, obviously, this isn't a good thing. I mean, I've been using Firefox 52-56 for many years, and I can toggle the Bookmarks Sidebar in 56.0.2 repeatedly and never see that happen. So maybe someone who cares should try fixing it. Thanks.

Component: Untriaged → Bookmarks & History

(In reply to gaveitatry from comment #0)

This is because this Firefox 66.0.5 loads the Sidebar on the right momentarily and then vanishes before it loads on the left

I don't see that. The only flickering I see on the right is the scrollbar quickly switching positions between the edge of the window and further left, at a distance that appears to be the width of the sidebar. Curiously, this doesn't seem to happen on in-content pages like about:support. I can see this as far back as Firefox 55, which didn't have an option to switch the sidebar to the right side.
On the left, the sidebar itself will of course flicker if you press Ctrl+B fast enough. I think that's unavoidable.

I can toggle the Bookmarks Sidebar in 56.0.2 repeatedly and never see that happen.

It would be helpful if you could find the exact regression range.
https://mozilla.github.io/mozregression/quickstart.html

Once you've finished testing all builds in the range, left-click the last one in the Bisection Progress list. Then under Bisection Information on the right, click the pushlog_url link to open it. Paste that link in a comment here.

Flags: needinfo?(postandreply)

On the left, the sidebar itself will of course flicker if you press Ctrl+B fast enough. I think that's unavoidable.

I'm definitely not talking about a left Sidebar flickering on the left. I'm talking about a ghost Sidebar flickering on the right in addition to the real Sidebar showing on the left.

I made a 30 second video demonstrating what happens when I toggle the Sidebar on/off on my offline home page. https://youtu.be/G7HLmivo0Lg It was worst and more noticeable before I edited my index.htm to remove all my iframe links to other htm pages. But you can still see the flickering every six or more seconds.

The only flickering I see on the right is the scrollbar quickly switching positions between the edge of the window and further left, at a distance that appears to be the width of the sidebar.

Do you mean like this? https://youtu.be/mYzTyJGQkJs It is a 10 second video of me toggling the Sidebar on/off on the Steam page in Firefox 66.0.5. You can't see very well in the video, but the scrollbar was definitely jumping left to right in addition to the ghost Sidebar flickering on the right. What's strange is that the scrollbar doesn't move at all on my offline home page. It's just the ghost Sidebar flickering. My guess is that Steam is more intensive and heavy that my offline website and so it caused additional problems.

Look. I made another 10 second video of me doing the toggle Sidebar thing on the same Steam page but in Firefox 62.0.5. It's a huge difference. Nothing wrong at all. https://youtu.be/X_88GtuBVtw

Once you've finished testing all builds in the range...

Sorry that I can't be of more help. I just can't devote any time and energy in testing builds right now, especially since I have no experience doing it. I haven't even made the switch from 56.0.2 to Quantum yet, and I am more focused on peeling that (cries) onion one layer at a time.

My guess is that performance wise Quantum is a little hacky. I think that in the case of my offline (not published online) home page, the more content and iframes that I had the more inclined it was to show a ghost Sidebar flickering on the right. As for the Steam page, that is a bit scary. It seems to be not doing the sidebar thing but also doing something weird with the scrollbar, which never happens to me in 56.0.2. I do know for testing purposes, you need a webpage with a dark background. I found this site http://www.e-try.com/black.htm which is just a blank black screen with no vertical or horizontal scrollbar. The problem with testing it out on this page is that you rarely ever see the aforementioned flickering. But if you are persistent enough and keep toggling the Sidebar, you will eventually see it after a hundred toggles or so. I think that the reason it is so hard to reproduce on this http://www.e-try.com/black.htm website is because it has very little CSS and HTML coding. I think this glitch is more noticeable on pages that has more than a <head> and <body> tag.

this doesn't seem to happen on in-content pages like about:support

Yeah, I don't really care about those pages. Most of the time, I am on my offline home page or a regular website. Whatever glitches and inconveniences that happen on those type of pages isn't of much concern to me since I don't spend a lot of time on them. It could be because those pages don't have a ton of content or are really well coded or something. Who knows? I wouldn't know.

I can see this as far back as Firefox 55, which didn't have an option to switch the sidebar to the right side.

Not sure what you mean. Do you mean you see the scrollbar shifting weirdly as far back as Firefox 55? Like I said, I've been using version 52-56, every day, all day, for many, many years and I never experienced anything like that or the ghost flickering before... until I tried 66.0.5.

I tried to give some relevant information, but I won't be able to do any more than this for now. Sorry.

Flags: needinfo?(postandreply)

but in Firefox 56.0.2*, not "but in Firefox 62.0.5". I made some typos. I don't know how to edit a post, so I made a new one.

Setting the regressionwindow-wanted keyword in case someone can find the regression range based on the videos at comment 2. The attached snapshot appears to show the flash in question.

Has Regression Range: --- → no
Has STR: --- → yes

It would be helpful if you could find the exact regression range.
https://mozilla.github.io/mozregression/quickstart.html

I might give this a try soon, within the next three or so days.

This problem did not exist for me in Firefox 56.0.2 (32-bit), but it did my first time trying Firefox 66.0.5 (64-bit).

My first time using Mozregression-gui, I tried all (64-bit) builds going back as far as 2017-10-27 (because I thought that was when my 56.0.2 came out), but I was not able to find a working build.

So I then checked all (64-bit) builds dating from 2017-10-27 to 2015-01-01. For some reason, it got stuck on 2015-05-10 and just showed a blank browser. I couldn't navigate to any pages. I clicked the 'Retry' button but nothing changed. I clicked 'Skip' and it switched to 2015-05-11, but it was just another blank browser that wouldn't let me navigate to any pages again. I clicked 'Skip' by mistake, when I meant to do 'Retry'. It switched me to 2015-05-09. Another blank browser.

I decided to call it quits and try the (32-bit) builds. I searched from last known good build 2017-10-18 to last known bad build 2019-05-18. It started me with 2018-08-03, which was bad. For some reason, it loaded 2018-08-03 really slow, and then it never even loaded 2018-03-12 at all. So I clicked 'Retry'. 'Retry' worked. I kept testing buildings up to 2017-10-19, and was not able to find a working build.

So I then checked all (32-bit) builds dating from last known good build 2015-01-01 to first known bad build 2017-10-18. It started me off with 2016-05-26 (which was very attractive, by the way, much better than newer versions). It was bad, so I kept going. 2015-05-09 might be what you call a "good build". I toggled that thing a a ton of times and only saw it do the ghost sidebar thing like once or twice, virtually never. Since it basically never did it, it is a good build. I decided to stop the tests for now and report back to you and see what you want me to do.

By the way, I am willing to retest it again on any 32-bit or 64-bit, for any dates, to make sure that I did it right and didn't make any mistakes (I'm overly cautious).

left-click the last one in the Bisection Progress list. Then under Bisection Information on the right, click the pushlog_url link to open it. Paste that link in a comment here.

Let's see...

https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=3c296aa11c51&tochange=9ed17db42e3e46f1c712e4dffd62d54e915e0fac

(In reply to gaveitatry from comment #6)

I decided to stop the tests for now

We're looking for a regression range that's between two autoland / inbound builds, which is even more precise than two nightlies (a single day apart). Your push log spans from January 1st to September 13th 2015; there's no way to find any suspect patches in all that.

Your push log spans from January 1st to September 13th 2015

Are you sure? Because every 32-bit from 2015-05-09 until today was "bad". And every 64-bit from 2015-05-10 until today was "bad".

I'm not sure what you want or why you are reprimanding me. Tell me in exact words what you want, and I'll try to do it.

I couldn't test 64-bit versions older than 2015-05-10 for some reason. And if all the 32-bit builds from today's date until 2015-05-19 were broken, and the 2015-05-19 one worked, why would I need to test back to 2015-01-01? I already explained in detail that I assumed my 56.0.2 build was dated around 2017-10. So I wasn't expecting to go back before 2017. To me 2017-10 was the first "good build". But when that didn't work, I had to use a random date to go back further than 2017-10. So that's why I chose a random date 2005-01-01. January 2015 is of no significance to me, I just needed to go back older than 2017-10 until I found a working build.

Let me try to explain one more time.

I tested all 64-bit builds from May 18, 2019 to Oct 27, 2017. And then from Oct 10, 2017 to May 10, 2015. Every build that I tested had the ghost sidebar bug. I would have tested back older than May 10, 2015, but it wouldn't let me.

I then tested all 32-bit builds from May 18, 2019 to Oct 18, 2017. And them from Oct 18, 2017 to Jan 01, 2015 (random date), when I came across the first working build of May 09, 2015. If May 09, 2015 worked, why are you complaining about not testing much older and more precise builds?

Wouldn't it make more sense to test the more precise builds from like Apr to Jun 2015, to find out exactly when it broke?

And you never answered my question of why I couldn't go back later than May 10, 2015 for the 64-bit browsers.

UPDATE:

I don't know if I am doing this right. This time I did it by releases instead of dates, from 5 to 67. I only tested the 32-bit ones this time. I plan to do the 64-bit ones next. Then do the 32-bit and 64-bits a second time.

1st time doing 32-bits with releases 5-67:

https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=17de0f463944&tochange=e90536aa55dd

2nd time doing a 32-bits with releases 5-67:

https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=acbd7b68fa8c&tochange=1427b365cd39

I did a 64-bits test, but it ended in a failure with build not loading. I give up testing 64-bits for now. I just want to find out which 32-bit version was the one that broke. I don't know how the hell to test "autoland / inbound builds". The only options I see are Build Type: shippable, opt, pgo, and debug. I have no idea what opt and pgo is, but I find it hard to believe that opt/pgo are abbreviations for autoland/inbound. And on the other page, I can only search by date or releases. Nothing else. So if you want me to do a test for "autoland / inbound builds" then show me how.

The default for the sidebar is to have it on the left (unless you're in an RTL version of Firefox). As far as I can see in that default state none of the code would be causing it to display on the right and then left again.

My suspicion is either display performance (maybe the whole browser content area is shifting across), or some other weird issue.

Moving across to general, as I don't think this would be a specific bookmarks and history issue.

From the regression range in comment 11 (note: comment 12 is a larger range but includes the same subset), the only thing potentially obvious I see is the enabling of E10s. That was quite a big switch, so could have caused the issue.

Component: Bookmarks & History → General

My suspicion is either display performance (maybe the whole browser content area is shifting across), or some other weird issue.

Yes, you are right. I only started using Quantum 2-3 days. I was using 56.0.2. So I didn't notice this at first. But it is doing just what you said. The whole browser content area is shifting across. I noticed this when I added some code to autohide the navigation bar.

:root:not([customizing]) #nav-bar {
-moz-window-dragging: default;
margin-top: -40px; opacity: 0;
transition: all 0s 0.5s !important;}

:root:not([customizing]) :hover > #nav-bar {
margin-top: 0px; opacity: 1;
transition: all 0s 0.25s !important;}

Whenever I toggled the navigation bar on/off, I saw a white space on the bottom of the page flicker for a second and it was the same size as the navigation bar. Just like my sidebar on the left creates a white space on the right that is the same size as the sidebar. So it is like you said. It is the whole browser content area shifting across.

It sounds like you have an idea of what caused it. Would be sweet if you can figure out a fix. Thanks, and I'm glad I finally found a good regression range that you can use. I'm new to this stuff.

Whenever I toggled the navigation bar on/off, I saw a white space on the bottom of the page flicker for a second and it was the same size as the navigation bar. Just like my sidebar on the left creates a white space on the right that is the same size as the sidebar. So it is like you said. It is the whole browser content area shifting across.

Here is a 6-7 second video that demonstrates the above.

https://youtu.be/Zp8eBQyoksg

I have a question. If my regression range is correct and this E10 problem existed since November 2014, why am I not noticing it in my 56.0.2 (32-bit) version that according to what I found online was released nearly three years later in September 2017?

I will uninstall mozregression for now. Let me know if you need me to reinstall it later on and run more tests.

Based on comment 11, comment 12 and comment 14 I will remove the regression window wanted keyword and set Has Regression Range flag to "yes".

Has Regression Range: no → yes

With comment 0 and comment 15 together, it sure looks like a graphics problem. Moving it there to see whether a graphics person can ask some helpful questions.

Component: General → Graphics
Product: Firefox → Core
Priority: -- → P3

There hasn't been an update in 25 days. Where are we on this? Also, should we rename the title since this affects more than just the bookmarks sidebar?

It's been six months. Are you making any progress on this???

This was opened 11 months ago. Still nothing. No progress.

(In reply to Drew Willcoxon :adw from comment #19)

With comment 0 and comment 15 together, it sure looks like a graphics problem. Moving it there to see whether a graphics person can ask some helpful questions.

Where is the graphics person? Are you telling me this is still unassigned after 11 months? Even now I can toggle the bookmarks sidebar or toggle navigation bar and it creates a "ghost" sidebar on opposite side of the window. Don't you guys want to fix that? I haven't deleted my YouTube videos from 11 months ago that show the problem. Just watch the videos and you can see it's not something any browser should have or be satisfied with.

Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: