Mac 1.8.1: Progress spinner misplaced when starting with multiple tabs

RESOLVED WONTFIX

Status

RESOLVED WONTFIX
12 years ago
10 years ago

People

(Reporter: mark, Unassigned)

Tracking

({regression})

1.8 Branch
mozilla1.8.1
PowerPC
Mac OS X
regression
Bug Flags:
blocking1.8.1 -

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(5 attachments)

(Reporter)

Description

12 years ago
When Bone Cho is started up and it opens multiple tabs, as is the case when you switch to Bone Cho after having used another version, the progress spinner will draw in the wrong location for the second tab.  This will be the first impression users get upon upgrading to Firefox 2, and it looks like ass.

The progress spinner belongs where the favicon is.  The evil frame is about 10px too low and about 26px too far to the left.

This does not occur on the trunk.  I was hoping bug 337545 would fix it, but it didn't.

If I dump all profiles and caches before starting Bone Cho, I get an even more disgusting effect on first startup.  This looks like bug 314900, which I'm now thinking wasn't fixed by bug 337545 either.
(Reporter)

Comment 1

12 years ago
Created attachment 231793 [details]
Fig. 1. Appearance after switching from Firefox 1.5 to Bone Cho
(Reporter)

Comment 2

12 years ago
Created attachment 231794 [details]
Fig. 2. Appearance while loading tabs in Bone Cho with a new profile and empty cache

This snapshot was taken while the tabs were still loading.
(Reporter)

Comment 3

12 years ago
Created attachment 231795 [details]
Fig. 3. Appearance with a new profile and empty cache after loading is finished
(Reporter)

Updated

12 years ago
Attachment #231794 - Attachment description: Fig. 2. Appearance after starting Bone Cho with a new profile and empty cache → Fig. 2. Appearance while loading tabs in Bone Cho with a new profile and empty cache
(Reporter)

Updated

12 years ago
Flags: blocking1.8.1?
(Reporter)

Comment 4

12 years ago
Comment on attachment 231794 [details]
Fig. 2. Appearance while loading tabs in Bone Cho with a new profile and empty cache

Fig. 2 is the most interesting to me.  It shows the reload button and the background of the leftmost tab being shifted by (220,13), which is the location bar's position relative to its parent (the window's content area).

With this in mind, we can see that the mispositioned spinner in fig. 1 and fig. 3 is not in fact the spinner from the rightmost tab being drawn 26px left of its expected location, but the spinner from the leftmost tab being drawn 220px to the right of its expected location.
(Reporter)

Comment 5

12 years ago
This is most likely to occur on an empty cache.  When the cache contains the documents to be loaded, there is minimal UI activity before layout is complete.

By setting browser.homepage.url to http://www.mozilla.com/firefox/central/|http://www.mozilla.org/projects/bonecho/index-2.0b1.html, I was able to compare 1.8.0.5 against 1.8.1b, after verifying that 1.8.1b shows this behavior on an empty cache when loading the home page in multiple tabs, as opposed to opening the first-run page in a tab by virtue of being first-run.  I have found that while similar problems exist in 1.8.0.5, they are more subdued and less easily reproduced.  This behavior is reproducible every time in 1.8.1b for me.  Marking regression for that reason.
Keywords: regression

Comment 6

12 years ago
I see this with my Bone Cho, too.
(Reporter)

Comment 7

12 years ago
Can someone QA this and figure out when it started happening?

Or, alternately, when it stopped happening on the trunk?
Keywords: qawanted
Mark, we're changing the tabbrowser-tabs binding again, and the binding changes to have closebuttons on tabs might well have caused this... please check again once those land.
Flags: blocking1.8.1? → blocking1.8.1+
(Reporter)

Comment 9

12 years ago
Will do, but the offsets I'm seeing make this look like a gfx/src/mac problem or an OS bug.
Mark: I saw this for the first time during testing yesterday. I will try to see if I can hunt down a regression range.
(Reporter)

Comment 11

12 years ago
Thanks, Marcia!  The STR I was using last week involved switching builds, dumping entire profiles, or dumping caches, with slightly different results for each.  Let me know if I can help reduce the STR further.
I played around with this a bit today on my PPC machine. I was able to reliably reproduce this starting on the 8-1 build, but then later I was not able to reproduce it again on that same build. The 7-25 build did not seem to show it, nor did the 7-31 build, but again my results might be suspect. Adam has been working on this too, let's see what results he comes up with. I will continue to investigate.

Comment 13

12 years ago
Sorry for not getting around to this earlier, Mark.

According to my research, this regressed between 2006-06-12-08 and 2006-06-13-04. Check-ins: http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=PhoenixTinderbox&branch=MOZILLA_1_8_BRANCH&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2006-06-12+07&maxdate=2006-06-13+05&cvsroot=%2Fcvsroot

FWIW, I reproduced this by enabling session restore by default and just clearing out my cache before I started each time.

Comment 14

12 years ago
Backing out the patch for bug 292865 fixes the issue with the progress spinners being misplaced, but can't tell if it fixes the random icon misplacement that Mark's seeing since I can't reproduce that.

Updated

12 years ago
Keywords: qawanted
(Reporter)

Comment 15

12 years ago
Thanks, Adam.  I'm pretty sure that what we've got is an origin bug with drawing images with CoreGraphics into a QuickDraw port, possibly triggered by a recent window resize.  The bug is either in our gfx code or in the system libraries.  Unfortunately, I'm unable to reproduce it today.

Comment 16

12 years ago
I can't reproduce this. 

Comment 17

12 years ago
Mark/Josh any further luck in reproducing
Target Milestone: --- → mozilla1.8.1

Comment 18

12 years ago
Created attachment 233931 [details]
Fig. 4. Appearance with Google and Slashdot set as homepage

I can't reproduce the issue with the tab throbbers being misplaced, but I did get the Google logo to show up on top of my toolbars... I just used "http://www.google.com/|http://slashdot.org" as my homepage, set Bon Echo to show my homepage each time I restarted, and wiped my cache before starting.
(Reporter)

Comment 19

12 years ago
F.
(Reporter)

Comment 20

12 years ago
That's the same bug - the Goog banner is being painted relative to the location bar's origin instead of the window's origin.

Comment 21

12 years ago
Pulling this off the blocking list as we can't seem to get consistent STR or see this often.  If we get either of those please re-nom.
Flags: blocking1.8.1+ → blocking1.8.1-

Comment 22

12 years ago
*** Bug 358487 has been marked as a duplicate of this bug. ***

Comment 23

12 years ago
*** Bug 358175 has been marked as a duplicate of this bug. ***

Comment 24

12 years ago
*** Bug 358218 has been marked as a duplicate of this bug. ***

Comment 25

12 years ago
*** Bug 354520 has been marked as a duplicate of this bug. ***
*** Bug 360172 has been marked as a duplicate of this bug. ***
*** Bug 363296 has been marked as a duplicate of this bug. ***

Comment 28

12 years ago
This bug doesn't require anything fancy for the home page ... in Firefox 2.0 (OS/X 10.4.8, iBook G4), if the tab bar is enabled, then the bug happens with www.google.com as the home page -- every time I've tried it.  Turn off the tab bar, and it doesn't happen.

It only happens at startup, not with a new tab or new window.

Comment 29

12 years ago
> It only happens at startup, not with a new tab or new window.
No, I've seen it happen with new windows, not only on startup. 
Opening a second tab in a window completely "repairs" the layout, though.

This issue also seems to be system load dependent. This bug is more likely to happen with high load.

Updated

12 years ago
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → WORKSFORME

Comment 30

12 years ago
Sorry. Wrong bug.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---

Comment 31

12 years ago
Created attachment 255328 [details]
Screenshot combination with several tabs

After opening a new window, opening a new tab which is immediately displayed fixes the layout. Apple-clicking on a link in the displayed page without immediately focusing the newly opened tab keeps the layout broken. 
The attached screenshot combination shows this (bookmarks are blacked out for privacy, the red lines are supposed to separate the single screenshots): 
* on top the broken layout, after initially opening a new window
* in the middle the still broken layout with some pieces good, and a second tab in the background, opened by Apple-Clicking a link in the start page
* below the correct layout, after opening a new empty tab with Apple-T

IMHO, the title " Progress spinner misplaced" does not correctly describe the problem, it should be more like "Opening a new window w/ tabs enabled breaks rendering (for some web sites)". 

Also, on a slower machine (such as mine), you can see that FF is starting to display the page right under the address bar, and then moving it to the right place. This is where the rendering artifacts in the uppermost screenshot are from.

Maybe this is related to bug #361664?
(Reporter)

Comment 32

12 years ago
(In reply to comment #31)
> Maybe this is related to bug #361664?

Nope, this is a Carbon gfx/widget bug (and possibly bad OS interaction) related to origins.

Comment 33

12 years ago
This problem (at least, the one where the Google graphic is initially misplaced when starting Firefox and with the "always show tab bar" preference enabled) appears to be fixed with version 2.0.0.2 on Mac OS X 10.4.8 (with the OS X updates current as of 26-feb-2007).

Comment 34

12 years ago
Sorry but the bug is still here on a clean Firefox 2.0.0.2 profile on MacOS 10.4.8 with all updates installed. I can reproduce it all the time, by following the simple steps outlined in comment #4 for bug 354520 which is marked as duplicate of this one.

Comment 35

12 years ago
Well, it is now fixed for me.  I was consistently seeing the misplaced graphic previously (clean cache), but now I do not, after the restart with the automatic update to 2.0.0.2 -- On an iBook G4:

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.2) Gecko/20070219 Firefox/2.0.0.2

I guess it goes to show the random (timing related?) nature of the bug if some are still seeing it occur.
Duplicate of this bug: 377465

Updated

12 years ago
Duplicate of this bug: 382433

Updated

11 years ago
Duplicate of this bug: 389200

Updated

11 years ago
Assignee: joshmoz → nobody
Status: REOPENED → NEW
(Assignee)

Updated

10 years ago
Product: Core → Core Graveyard
Not going to fix this on 1.8.1, where it exists. WONTFIX.
Status: NEW → RESOLVED
Last Resolved: 12 years ago10 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.