41.54 KB, image/png
29.73 KB, image/png
39.96 KB, image/png
67.30 KB, image/png
85.49 KB, image/jpeg
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.
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.
Created attachment 231795 [details] Fig. 3. Appearance with a new profile and empty cache after loading is finished
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
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.
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 22.214.171.124 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 126.96.36.199, 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.
I see this with my Bone Cho, too.
Can someone QA this and figure out when it started happening? Or, alternately, when it stopped happening on the trunk?
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+
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.
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.
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.
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.
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.
I can't reproduce this.
Mark/Josh any further luck in reproducing
Target Milestone: --- → mozilla1.8.1
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.
That's the same bug - the Goog banner is being painted relative to the location bar's origin instead of the window's origin.
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-
*** Bug 358487 has been marked as a duplicate of this bug. ***
*** Bug 358175 has been marked as a duplicate of this bug. ***
*** Bug 358218 has been marked as a duplicate of this bug. ***
*** 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. ***
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.
> 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.
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → WORKSFORME
Sorry. Wrong bug.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
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?
(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.
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 188.8.131.52 on Mac OS X 10.4.8 (with the OS X updates current as of 26-feb-2007).
Sorry but the bug is still here on a clean Firefox 184.108.40.206 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.
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 220.127.116.11 -- On an iBook G4: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:18.104.22.168) Gecko/20070219 Firefox/22.214.171.124 I guess it goes to show the random (timing related?) nature of the bug if some are still seeing it occur.
Product: Core → Core Graveyard
Not going to fix this on 1.8.1, where it exists. WONTFIX.
Status: NEW → RESOLVED
Last Resolved: 12 years ago → 10 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.