scrollbars not showing correct state when switching tabs

RESOLVED WORKSFORME

Status

--
minor
RESOLVED WORKSFORME
14 years ago
8 years ago

People

(Reporter: mozilla, Assigned: jaas)

Tracking

Trunk
PowerPC
Mac OS X
Bug Flags:
blocking1.8b3 -
blocking1.8b5 -

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

14 years ago
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

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

Comment 2

14 years ago
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

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

Comment 4

14 years ago
Created attachment 171698 [details]
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

14 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
*** Bug 276304 has been marked as a duplicate of this bug. ***
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 8

14 years ago
Anybody working on this? 
Flags: blocking1.8b2+
Martin, are you a driver?  If not, you shouldn't be setting the flag you set...
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

14 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

14 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

14 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

14 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.)
This sounds like a pretty serious issue that we need to fix for beta...
Flags: blocking1.8b2?

Comment 16

14 years ago
I wonder if this is related to bug 281455?
Possible, yes...
Depends on: 281455

Comment 18

14 years ago
I don't see this in FF; must be something the modern skin is doing.
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

14 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

14 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

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

Comment 23

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

Updated

14 years ago
Flags: blocking1.7.6?

Comment 24

14 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

14 years ago
Flags: blocking1.8b2? → blocking1.8b2+

Comment 25

14 years ago
->josh
Assignee: sfraser_bugs → joshmoz
hopefully for 1.8b3.
Flags: blocking1.8b2+ → blocking1.8b3+

Updated

14 years ago
Flags: blocking1.7.6?

Comment 27

14 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?
> 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.

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

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

Comment 31

14 years ago
Same root cause as bug 300095?
Josh, any chance of getting this into 1.5?
Flags: blocking1.8b4?
(Assignee)

Comment 33

14 years ago
Its possible, but don't block on it.

Updated

14 years ago
Flags: blocking1.8b4? → blocking1.8b4-

Comment 34

14 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

14 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

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

Comment 39

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

Comment 40

14 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

14 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
Last Resolved: 14 years ago
Resolution: --- → WORKSFORME

Updated

9 years ago
Component: Widget: Mac → Widget: Mac
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.