347046 - Mac 1.8.1: Progress spinner misplaced when starting with multiple tabs

Status: RESOLVED WONTFIX

(Core Graveyard :: GFX: Mac, defect)

Description

[Mark Mentovai]

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.

Comment 1

[Mark Mentovai]

Attachment: Fig. 1. Appearance after switching from Firefox 1.5 to Bone Cho

Comment 2

[Mark Mentovai]

Attachment: 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.

Comment 3

[Mark Mentovai]

Attachment: Fig. 3. Appearance with a new profile and empty cache after loading is finished

Comment 4

[Mark Mentovai]

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.

Comment 5

[Mark Mentovai]

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.

Comment 6

[Adam Guthrie]

I see this with my Bone Cho, too.

Comment 7

[Mark Mentovai]

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

Or, alternately, when it stopped happening on the trunk?

Comment 8

[Mike Connor [:mconnor]]

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.

Comment 9

[Mark Mentovai]

Will do, but the offsets I'm seeing make this look like a gfx/src/mac problem or an OS bug.

Comment 10

[Marcia Knous [:marcia]]

Mark: I saw this for the first time during testing yesterday. I will try to see if I can hunt down a regression range.

Comment 11

[Mark Mentovai]

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.

Comment 12

[Marcia Knous [:marcia]]

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

[Adam Guthrie]

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

[Adam Guthrie]

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.

Comment 15

[Mark Mentovai]

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

[Josh Aas]

I can't reproduce this. 

Comment 17

[Mike Schroepfer]

Mark/Josh any further luck in reproducing

Comment 18

[Adam Guthrie]

Attachment: 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.

Comment 19

[Mark Mentovai]

F.

Comment 20

[Mark Mentovai]

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

[Mike Schroepfer]

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.

Comment 22

[Adam Guthrie]

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

Comment 23

[Adam Guthrie]

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

Comment 24

[Adam Guthrie]

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

Comment 25

[Adam Guthrie]

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

Comment 26

[Ria Klaassen (not reading all bugmail)]

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

Comment 27

[Phil Ringnalda (:philor)]

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

Comment 28

[Dan Cornett]

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

[Kurt Jaeke]

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

Comment 30

[Josh Aas]

Sorry. Wrong bug.

Comment 31

[Kurt Jaeke]

Attachment: 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?

Comment 32

[Mark Mentovai]

(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

[Dan Cornett]

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

[Marco De Vitis]

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

[Dan Cornett]

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.

Comment 39

[Samuel Sidler (old account; do not CC)]

Not going to fix this on 1.8.1, where it exists. WONTFIX.