278812 - scrollbars not showing correct state when switching tabs

Status: RESOLVED WORKSFORME

(Core Graveyard :: Widget: Mac, defect)

Description

[Bjarne D Mathiesen]

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

Comment 1

[Bjarne D Mathiesen]

Forgot this:
This issue is confined to the modern theme -
it's not present in the classic theme

Comment 2

[HJ]

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?

Comment 3

[Bjarne D Mathiesen]

HJ:'
There's no javascript errors related to Mozilla itself
Please re-read step 1) in how to reproduce

Comment 4

[Bjarne D Mathiesen]

Attachment: screenshot showing problems

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

[David Sowder]

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

[Boris Zbarsky [:bzbarsky]]

*** Bug 276304 has been marked as a duplicate of this bug. ***

Comment 7

[Boris Zbarsky [:bzbarsky]]

This is likely a regression from the "don't reflow background tabs" change...
Simon, Javier, any idea why the scrollbars are not being invalidated?

Comment 8

[Gulliver]

Anybody working on this? 

Comment 9

[Boris Zbarsky [:bzbarsky]]

Martin, are you a driver?  If not, you shouldn't be setting the flag you set...

Comment 10

[Asa Dotzler [:asa]]

Unsetting the flag. I forgot to lock this flag down to just the drivers group.
I'll remedy that now.

Comment 11

[Gulliver]

(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

[David Sowder]

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

[Gulliver]

(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

[David Sowder]

(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

[Boris Zbarsky [:bzbarsky]]

This sounds like a pretty serious issue that we need to fix for beta...

Comment 16

[Simon Fraser [no longer active]]

I wonder if this is related to bug 281455?

Comment 17

[Boris Zbarsky [:bzbarsky]]

Possible, yes...

Comment 18

[Simon Fraser [no longer active]]

I don't see this in FF; must be something the modern skin is doing.

Comment 19

[Boris Zbarsky [:bzbarsky]]

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

[Gulliver]

(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

[David Sowder]

(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

[David Sowder]

It looks like scollbars for frames may also have a similar problematic behavior:
http://philiphii.com/

Comment 23

[Gulliver]

Still present in Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; de-AT; rv:1.8b)
Gecko/20050217.

Comment 24

[Gulliver]

(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?

Comment 25

[Simon Fraser [no longer active]]

->josh

Comment 26

[Asa Dotzler [:asa]]

hopefully for 1.8b3.

Comment 27

[Gulliver]

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

[Boris Zbarsky [:bzbarsky]]

> 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 [e-mail]).

> 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

[Asa Dotzler [:asa]]

Kevin, can you help us look into this? If we can come up with a fix, we should
try to get it in.

Comment 30

[Simon Fraser [no longer active]]

Maybe related to one of the painting issues (e.g. bug 289353)?

Comment 31

[Simon Fraser [no longer active]]

Same root cause as bug 300095?

Comment 32

[Asa Dotzler [:asa]]

Josh, any chance of getting this into 1.5?

Comment 33

[Josh Aas]

Its possible, but don't block on it.

Comment 34

[Mark Mentovai]

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

Comment 35

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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.)

Comment 36

[Bjarne D Mathiesen]

(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

[Gulliver]

(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.

Comment 38

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Actually, the 1.7.3/1.7.5 regression date does match, so never mind...

Comment 39

[Adam Guthrie]

*** Bug 305164 has been marked as a duplicate of this bug. ***

Comment 40

[Gulliver]

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

[Mark Mentovai]

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.

Comment 42

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I think it's pretty clear that bug 227361 broke it, and it's likely that bug
285445 fixed it.