Closed
Bug 278812
Opened 20 years ago
Closed 19 years ago
scrollbars not showing correct state when switching tabs
Categories
(Core Graveyard :: Widget: Mac, defect)
Tracking
(Not tracked)
RESOLVED
WORKSFORME
People
(Reporter: mozilla, Assigned: jaas)
References
()
Details
Attachments
(1 file)
219.50 KB,
image/png
|
Details |
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.5) Gecko/20041217
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8a5) Gecko/20041122
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8a6) Gecko/20050111
This issue is not present in rv:1.7.3 and rv:1.8a4
Steps to Reproduce:
1) switch on : Load links in the background ;
Cmd-click or Cmd+Return on links in a Web page
2) Go to the URL given and open a few news items in new tabs
3) Scroll to the bottom of the index page (or just any amount down)
4) Switch to any other tab
Actual Results
1) The scrollbars - both at the right and at the bottom - are taken over from
the first tab
2) Sometimes, the contents of a previous tab is displayed instead of the scrollbar
3) When initiating scrolling in the tab the correct state of the scrollbars is
shown/updated
Expected Results
1) scrollbars should display the position of the page that's shown in the tab
Reporter | ||
Comment 1•20 years ago
|
||
Forgot this:
This issue is confined to the modern theme -
it's not present in the classic theme
Bjarne, do you see any JavaScript errors on the JavaScript console?
You need to set the pref to open cmd+clicks in new tabs instead of new windows,
right?
P.s. what about a little screenshot?
Reporter | ||
Comment 3•20 years ago
|
||
HJ:'
There's no javascript errors related to Mozilla itself
Please re-read step 1) in how to reproduce
Reporter | ||
Comment 4•20 years ago
|
||
1) the horizontal scrollbar is in the position of the contents of the first tab
it has been brougth all the way across all of the tabs in that position
2) the horizontal scrollbar is completely missing,
but space has been set off for it in the window.
the contents is a little bit wider than the window.
3) where the horizontal scrollbar ought to have been
you can see content from the third tab
NB: I do know that the screenshot is with a lot of xpi's installed, but these
issue !are! present in a plain vanila install of Moz as described
Comment 5•20 years ago
|
||
Here's the Javascript error I get for this problem. When switching to a tab,
the vertical scrollbar is not getting drawn, thus either the screen still
contains the pixels for the scrollbar of the tab switched from instead of the
expected scrollbar or the screen contains the pixels from the switched from tab
where the scrollbar should have been drawn for the switched to tab.
Error: this.docShell has no properties
Source File: chrome://global/content/bindings/browser.xml
Line: 0
Comment 6•20 years ago
|
||
*** Bug 276304 has been marked as a duplicate of this bug. ***
Comment 7•20 years ago
|
||
This is likely a regression from the "don't reflow background tabs" change...
Simon, Javier, any idea why the scrollbars are not being invalidated?
Assignee: guifeatures → sfraser_bugs
Component: XP Apps: GUI Features → Widget: Mac
Product: Mozilla Application Suite → Core
Version: 1.7 Branch → Trunk
Comment 9•20 years ago
|
||
Martin, are you a driver? If not, you shouldn't be setting the flag you set...
Comment 10•20 years ago
|
||
Unsetting the flag. I forgot to lock this flag down to just the drivers group.
I'll remedy that now.
Flags: blocking1.8b2+
Comment 11•20 years ago
|
||
(In reply to comment #9)
> Martin, are you a driver? If not, you shouldn't be setting the flag you set...
Well, no. But it worked and at least somebody got reminded of this bug.
Comment 12•20 years ago
|
||
Also found another bit of information on this issue. The problem only shows up
when the tab is first viewed:
1) Given tab A, Cmd-click to open tabs B and C in the background.
2) Switch to tab B, where the problem is visible.
3) Switch to tab C, where the problem is also visible.
4) Switch back to tab B, where the problem is no longer there.
Comment 13•20 years ago
|
||
(In reply to comment #12)
> Also found another bit of information on this issue. The problem only shows up
> when the tab is first viewed:
>
> 1) Given tab A, Cmd-click to open tabs B and C in the background.
> 2) Switch to tab B, where the problem is visible.
> 3) Switch to tab C, where the problem is also visible.
> 4) Switch back to tab B, where the problem is no longer there.
David,
this is valid if the scrollbars show wrong lenght and/or position. Unfortunately
this is not valid when the scrollbar does not appear at all unless you click
into the area where it should be. Try it on http://discussions.info.apple.com/.
Select an forum and open several threads in new tabs in the background.
Switching between these tabs will show the behaviour that you describe unless
there are a few that do not show any scrollbar at all.
Comment 14•20 years ago
|
||
(In reply to comment #13)
> (In reply to comment #12)
> > Also found another bit of information on this issue. The problem only shows up
> > when the tab is first viewed:
> >
> > 1) Given tab A, Cmd-click to open tabs B and C in the background.
> > 2) Switch to tab B, where the problem is visible.
> > 3) Switch to tab C, where the problem is also visible.
> > 4) Switch back to tab B, where the problem is no longer there.
>
> David,
>
> this is valid if the scrollbars show wrong lenght and/or position. Unfortunately
> this is not valid when the scrollbar does not appear at all unless you click
> into the area where it should be. Try it on http://discussions.info.apple.com/.
> Select an forum and open several threads in new tabs in the background.
> Switching between these tabs will show the behaviour that you describe unless
> there are a few that do not show any scrollbar at all.
You're right. If B doesn't need a scrollbar, it's fine and C (needing a
scrollbar) "inherits" the graphic from the screen portion of B where the
scrollbar should be in C. If B needs a scrollbar, it "inherits" the graphic
from the screen portion of A where the scrollbar should be on C. (And C the
same way.)
Comment 15•20 years ago
|
||
This sounds like a pretty serious issue that we need to fix for beta...
Flags: blocking1.8b2?
Comment 16•20 years ago
|
||
I wonder if this is related to bug 281455?
Comment 18•20 years ago
|
||
I don't see this in FF; must be something the modern skin is doing.
Comment 19•20 years ago
|
||
The modern skin binds some XBL to the scrollbars... could that be an issue here?
More to the point, are people seeing this with trunk builds newer than
2005-02-13? That's when some wallpaper for bug 280541 got landed.
Comment 20•20 years ago
|
||
(In reply to comment #15)
> This sounds like a pretty serious issue that we need to fix for beta...
Thanks! Resetting the flag?
Comment 21•20 years ago
|
||
(In reply to comment #19)
> The modern skin binds some XBL to the scrollbars... could that be an issue here?
>
> More to the point, are people seeing this with trunk builds newer than
> 2005-02-13? That's when some wallpaper for bug 280541 got landed.
It still a problem on Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US;
rv:1.8b2) Gecko/20050221
Comment 22•20 years ago
|
||
It looks like scollbars for frames may also have a similar problematic behavior:
http://philiphii.com/
Comment 23•20 years ago
|
||
Still present in Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; de-AT; rv:1.8b)
Gecko/20050217.
Comment 24•20 years ago
|
||
(In reply to comment #23)
> Still present in Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; de-AT; rv:1.8b)
> Gecko/20050217.
... and also in Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; de-AT; rv:1.8b2)
Gecko/20050327.
Anybody working on this?
Updated•20 years ago
|
Flags: blocking1.8b2? → blocking1.8b2+
Updated•20 years ago
|
QA Contact: mac
Updated•20 years ago
|
Flags: blocking1.7.6?
Comment 27•20 years ago
|
||
In the latest built Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; de-AT;
rv:1.8b2) Gecko/20050504 the scrollbars are only a few pixels broad, hardly
broad enough to click them. No arrows visible (probably too narrow to see them).
Are there any new nightly builts later than May 4th?
Do we have to switch to Safari right away or will there be any more versions for
Mac?
Could not find any informatiuon on the Seamonkey site about a Mac version. Will
there be one?
Comment 28•20 years ago
|
||
> No arrows visible (probably too narrow to see them).
That's a known issue, fixed since then.
> Are there any new nightly builts later than May 4th?
For Mac? I don't see any on FTP... file a bug, please ("mozilla.org" product,
"FTP Staging" component; you might want to cc chase@mozilla.org).
> Could not find any informatiuon on the Seamonkey site about a Mac version.
That should be asked of the Seamonkey people, not in this bug.
Comment 29•20 years ago
|
||
Kevin, can you help us look into this? If we can come up with a fix, we should
try to get it in.
Flags: blocking1.8b3+ → blocking1.8b3-
Comment 30•20 years ago
|
||
Maybe related to one of the painting issues (e.g. bug 289353)?
Comment 31•20 years ago
|
||
Same root cause as bug 300095?
Assignee | ||
Comment 33•20 years ago
|
||
Its possible, but don't block on it.
Updated•20 years ago
|
Flags: blocking1.8b4? → blocking1.8b4-
Comment 34•19 years ago
|
||
Is this still a problem? I couldn't reproduce it by following the steps in
comment 0 using a current SeaMonkey with the Modern theme.
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20050819
SeaMonkey/1.0a
Maybe fixed by the fix to bug 285445, although I don't even understand from the
earlier comments what the bug is, and comment 0's assertion that it was a
regression between 1.7.3 and 1.7.5 seems unlikely and probably misleading.
(Other than that, the regression dates do match bug 227361.)
Reporter | ||
Comment 36•19 years ago
|
||
(In reply to comment #35)
> Maybe fixed by the fix to bug 285445, although I don't even understand from the
> earlier comments what the bug is, and comment 0's assertion that it was a
> regression between 1.7.3 and 1.7.5 seems unlikely and probably misleading.
> (Other than that, the regression dates do match bug 227361.)
I'm standing by my statements in comment 0
Everything was exhaustively tested in completely new installs of Mozilla as well
as using completely fresh profiles. I !do! know how to test properly ;-)
Comment 37•19 years ago
|
||
(In reply to comment #34)
> Is this still a problem? I couldn't reproduce it by following the steps in
> comment 0 using a current SeaMonkey with the Modern theme.
>
> Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20050819
> SeaMonkey/1.0a
Mark,
this seems to be correct. I cannot see this problem in Mozilla/5.0 (Macintosh;
U; PPC Mac OS X Mach-O; de-AT; rv:1.9a1) Gecko/20050824 SeaMonkey/1.0a either.
What about the Mozilla nightlys? 1.7.11 from Gecko/20050824 still shows this
problem.
Actually, the 1.7.3/1.7.5 regression date does match, so never mind...
Comment 39•19 years ago
|
||
*** Bug 305164 has been marked as a duplicate of this bug. ***
Comment 40•19 years ago
|
||
This problem seems to be solved with built Mozilla/5.0 (Macintosh; U; PPC Mac OS
X Mach-O; en-US; rv:1.9a1) Gecko/20050829 SeaMonkey/1.1a.
Comment 41•19 years ago
|
||
This is WORKSFORME on the trunk and 1.8 branch unless someone can pinpoint the
precise bug that fixed it, in which case it would be DUPLICATE. Because it
apparently regressed between 1.7.3 and 1.7.5, someone could argue that it ought
to be fixed in 1.7 (blocking1.7.12). I'm not going to make that argument: if it
was important enough, someone would have (or should have) marked blocking1.7.x+
when it made sense to put effort into that branch. If I'm off base and someone
else wants to request, go for it.
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → WORKSFORME
I think it's pretty clear that bug 227361 broke it, and it's likely that bug
285445 fixed it.
You need to log in
before you can comment on or make changes to this bug.
Description
•