Closed Bug 313639 Opened 19 years ago Closed 19 years ago

Phantom Scrollbars are back

Categories

(Core Graveyard :: Widget: Mac, defect)

Product:
Core Graveyard
Component:
Widget: Mac
Version:
1.8 Branch
Platform:
PowerPC
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: lc__fc-xx001xx, Assigned: mark)

References

(
URL
)

Details

(Keywords: fixed1.8)

Attachments

(1 file)

the backout
4.38 KB, patch
Details | Diff | Splinter Review
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b5) Gecko/20051024 Firefox/1.5 Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b5) Gecko/20051024 Firefox/1.5 On some pages the vertical scrollbar doesn't work or has massive problems: e.g. this page here: https://bugzilla.mozilla.org/enter_bug.cgi?product=Firefox or http://www.bild.t-online.de/BTO/index.html Sometimes after scrolling long pages suddenly in the upper left corner, left of the back button, the uupper part of a vertical scrollbar is displayed. It covers the navigation toolbar, the bookmarks toolbar and the bar with the tabs. Opening a new tab removed that scrollbar top completely again. It just seems to be a Mac problem. Reproducible: Always Steps to Reproduce: 1. visit http://www.bild.t-online.de/BTO/index.html or https://bugzilla.mozilla.org/enter_bug.cgi?product=Firefox Actual Results: Scrolling by pulling down or up the blue button of the vertical scrollbar is impossible or the page jump up or down unexpectedly. Expected Results: Scrolling by pulling down or up the blue button of the vertical scrollbar works smoothly. I've been having this problems dozens of times a day lately, it's very obvious.
Does the "ghost" scrollbar appear when you try to scroll pages that hasn't finished loading? Like bug 304607?
Assignee: nobody → joshmoz
Component: General → Widget: Mac
Product: Firefox → Core
QA Contact: general → mac
Version: unspecified → 1.8 Branch
Initially fixed in bug 298677, regression from bug 311399 checkin.
Status: UNCONFIRMED → NEW
Ever confirmed: true
*** Bug 313668 has been marked as a duplicate of this bug. ***
Assignee: joshmoz → mark
I'm looking at the various options here.
Summary: On some pages vertical scrollbar doesn't work → Phantom Scrollbars are back
I am going to nominate this bug. I was showing it to Rafael this morning, and I think we both agree that we probably don't want to ship RC1 with this bug. From a usability standpoint I find it hard to use the vertical scrollbar on many sites. And in general the UI just doesn't look pleasant with its array of extra scrollbars. I can attach more screenshots if necessary.
Flags: blocking1.8rc1?
The regression window seems to be between 20051022 and 20051025. I wasn't seeing this bug until I updated my nightly build. To my untrained eye, it seems to have something to do with the way we interpret the mouseDown event on the scollbar, as even the throbber stops throbbing when that button is pressed.
As a follow-up diagnostic comment, I'm only seeing the inappropriate behaviour when a page (in any tab) is loading. When all the content is loaded, things seem to act normally.
Scrolling in other tabs is also affected if the test URL is loaded in it's own tab. Looks like a dupe of bug 304607.
Guys, guys, guys, thanks for the regression QA tracking, but we know what caused this (comment 2): bug 311399. Bug 304607 has been a rare problem all along, but the change in bug 311399 made us far more susceptible to it. It's mostly a separate bug. The patch in bug 304607 will solve these issues and more, but we can't take it without causing bug 300058 (attachment 188648 [details]), which really sucks too. Backing out the temporary fix from bug 311399 will reintroduce the Mac topcrashers. I'm looking at bug 304607 to see if there's something that can be done there without causing bug 300058. If any Carbon developers have any idea why the simple registration of a kControlDrawEvent handler on a scrollbar causes a one-pixel dead area in the track, please let me know.
We didn't mean to approve Bug 311399 anyway, see the big comment I put in that bug when we minused it explaining things (https://bugzilla.mozilla.org/show_bug.cgi?id=311399#c8). I'll back it out and then Chase and I can respin the bits again. It's unfortuante that this happened but at least we noticed it before RC went out the door.
Flags: blocking1.8rc1? → blocking1.8rc1+
So that everyone can make an informed decision, as things stand now, there are three options: (1) We can back the workaround in bug 311399 out. That will restore the crashes in bug 311399 [@ SetOrigin] and bug 312119 [@ QDPlatformGlobalToLocal]. My understanding of these bugs now tells me that these crashes occur on sites that use <select> popups to load pages, if the <select> is worked while the page is being reflowed (such as before a page has finished loading). These crashes are by far the topcrashers on the Mac, representing a total 319 crashes over the past 10 days. Considering that the top cross-platform crasher has 680 over the same period, and the small fraction of Mac users out of all tier-1 users, I'd say that this issue is very serious and one that users are likely to hit. http://talkback-public.mozilla.org/reports/firefox/FF15b2/smart-analysis.mac . (2) We can leave things as they are right now. That leaves a pretty ugly aesthetic and functional regression if the scrollbar is worked while the page is loading. There are no known impacts after the page has finished loading, except for the rare cases in bug 304607. (3) We can go with a form of the patch in bug 304607, which causes a guaranteed ugly aesthetic regression, but has no functional issues. I've been spending most of my time since yesterday afternoon trying to figure out how to do this without the aesthetic regressions, but so far, no go. As much as I hate to say it, (2) might be the safest option. I'd really hate to put a likely crash back into the codebase, and when it comes down to a topcrasher being pitted against an aesthetic issue, my own preference is to live with something ugly. Sorry for the last-minute regression here - because bug 304607 looks exactly like this bug, I didn't realize that bug 311399 made the issue much more common. I'll back out if that's what the drivers consensus is.
Flags: blocking1.8rc1+ → blocking1.8rc1?
mscott set blocking+, bugzilla has been pretty bad about these flags (since the upgrade?)
Thanks for the comments Mark. I would agree with you on option #2, except I think this bug is actually a lot worse than you think. It turns out if any tab is currently loading content then you are unable to scroll through any of the other tabs. I can reproduce this reading any web page that requires vertical scrollbars if I have content loading in another tab. In my case, this test case was taking a long time to load so all my tabs were demonstrating the scrolling problem. The only way I can scroll on most web pages is by clicking on the scroll thumbs. In short, I think this UI regression is a lot more visible than we think.
i meant to plus this bug :)
Flags: blocking1.8rc1? → blocking1.8rc1+
Mark, further thoughts based on my comment above?
I can definitely see this happening. I'm able to scroll in non-loading tabs, but it's jumpy, and the jump frequency depends on the size and loading speed of the tabs that are loading. I once came up with a hack to fix these jolts (attachment 188402 [details] [diff] [review]) that would work in a pinch (comes from bug 298677, where we initially saw all of these issues). It throws out scrollbar values known to be bad. A better solution here too would involve an event handler - this could probably even be done along the same lines of the event handler in (3), but without the drawing regressions. For the drawing side, I'm going to poke Apple about option (3) to see if they know where the artifacts are coming from and how to get rid of them. If the timeframe for rc1 is too tight, then backing out may actually be the best option. I just don't feel great leaving a topcrasher in place when we know what causes it and how to fix it.
(In reply to comment #16) > If the timeframe for rc1 is too tight, then backing out may actually be the > best option. I just don't feel great leaving a topcrasher in place when we > know what causes it and how to fix it. At the momoment this is our last bug for 1.5 and we're waiting to respin the bits once we figure out the right thing to do tonight. If the problem was local to just the tab that was loading, I would be more comfortable saying we should just leave the crash fix in. Reading one tab while content is loading in another tab (or another tab is slow to load) seems pretty common though.
Attached patch the backout — — Splinter Review
here's the patch we used to back this out. We talked with QA and some other folks and everyone thought this was too painful to ship with even though it means adding back the top crash bug.
fixed by back out.
Blocks: 311399
Status: NEW → RESOLVED
Closed: 19 years ago
Keywords: fixed1.8
Resolution: --- → FIXED
Testing with Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8) Gecko/20051025 Firefox/1.5 ID:2005102519 shows that vertical scrolling works again, while the phantom scrollbars still show up, when a tab is (re-)loading in the background.
Remaining issues are bug 304607.
I just wanted to mention that yesterday when I was testing this bug I was able to see the phantom scrollbars without any tabs open/loading. I could reproduce it by just going to to a bugzilla bug and clicking in the vertical scrollbar area a few times. I will test this in today's build.
Dex: you made a comment in Asa's blog about the 2005102519 build still exhibiting the phantom toolbar problem, and that it is gone in the 2005102603 build. While I have been testing the 2005102519 build I have not seen any of these crop up. Also, I thought mscott's backout made it into that build. Can you please provide some steps to reproduce? Before I was seeing this all the time, including the URL you reference in the bug, but in the 2005102519 build I have yet to see it. (In reply to comment #20) > Testing with Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8) > Gecko/20051025 Firefox/1.5 ID:2005102519 shows that vertical scrolling works > again, while the phantom scrollbars still show up, when a tab is (re-)loading > in the background. >
I'm unable to reproduce this problem using the -19 build which did contain the back out. There were several other builds from earlier that day on the 25th which still fail.
Marcia: I reinstalled 2005102519, and while the problem still appeared, I needed quite a while to find a way to reproduce the problem: 1. load http://www.auto-motor-und-sport.de/ (it worked with http://my.yahoo.com/ incl several activated news, mail and other modules as well), 2. activate the Reload Every extension with 10s to make sure that tab is reloaded in the background and to get a faster result, 3. open a new tab and load http://www.spreadfirefox.com/ 4. play with the vertical scrollbar for a while, pull it up and down a few times, leave it for a few moments and repeat pulling it up and down a few times, repeat step 4. In my tests step 4 never required more than 3 minutes. That way I was able to reproduce the bug 8 times within 20 minutes, I also could provide screenshots if they are needed. With 2005102603 I wasn't able to reproduce the problem on this way nor on another way.
In comment 11, option (3), although the right thing to do, was unsuitable because it introduces artifacts in scrollbars (bug 300058). In bug 304607, I commented that these artifacts are only present in 10.4.0 - 10.4.2 and will be fixed in an upcoming OS release.
After installing the rc1 on my Mac it lasted less than 2 min of running it to get a Phantom Scrollbar. The OS X has changed to v10.4.3 now. Reproducable as mentioned in #25.
(In reply to comment #27) > After installing the rc1 on my Mac it lasted less than 2 min of running it to > get a Phantom Scrollbar. The OS X has changed to v10.4.3 now. Reproducable as > mentioned in #25. I can't confirm this bug using those steps w/RC1 on OS 10.4.3. The only thing I'm seeing is that when I pull the scrollbars in the second tab, the throbber on the first tab stops. Please make sure you're using a clean profile and no extensions, and if you're still experiencing the problem, I'll look into it again.
Dex, you're probably experiencing bug 304607 - you will occasionally see phantom scrollbars drawing at the top left corner while some pages are loading (background, foreground, whatever) and a scrollbar is operated. I'm working on a more complete fix for that bug (and others).
(In reply to comment #29) Mark, yep, that's possible as well, although it's still existing in 10.4.3. Thanks a lot for the heads up and all the hard work on fixing both of them. Dex
10.4.3 doesn't fix any perceptible visual artifacts in scrollbars. It merely makes it possible for us to use a specific apprroach to solve the phantom scrollbar problem without introducing other visual artifacts.
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: