Open Bug 571918 Opened 10 years ago Updated 8 months ago

title of an opened tab keeps showing "Loading" when using a Persona

Categories

(Core :: General, defect)

x86
Windows XP
defect
Not set

Tracking

()

Tracking Status
blocking2.0 --- -

People

(Reporter: Event.H04iz0n, Unassigned)

References

()

Details

(Keywords: regression, Whiteboard: [4b2])

Attachments

(3 files, 1 obsolete file)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a6pre) Gecko/20100614 Minefield/3.7a6pre ( .NET CLR 3.5.30729) Firefox/3.6.3
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a6pre) Gecko/20100614 Minefield/3.7a6pre ( .NET CLR 3.5.30729) Firefox/3.6.3

If I use a theme other than the Default (ex: Niagra Falls, Yosemite, Dark Fox),
when I click on the following link the 'Tab' title will be 'Loading...', until the page is redrawn (ex: if I click on a different tab; then the correct Tab title appears).

Example:
  * #543206 [Firefox:Tabbed Browser]-Tab opening animation [All]
  https://bugzilla.mozilla.org/show_bug.cgi?id=543206

If I switch to the Default theme it seems to work.

Reproducible: Always

Steps to Reproduce:
1. Use a theme other than Default (ex: Dark Fox).
2. Left click a URL (a link will open a new Tab), or Center Button click (to force it to open in a new tab).
3. New tab opens with the title 'Loading...'
Actual Results:  
Tab opens with the title 'Loading...'.

Expected Results:  
New tab open with title that matches the Window Title bar.
Attached image ScreenShot
Conformed on
Mozilla/5.0 (Windows; U; Windows NT 5.1; pl-PL; rv:1.9.3a6pre) Gecko/20100614 Minefield/3.7a6pre
I was mistaken (technically) they are Persona's (Niagra Falls, Yosemite, Dark Fox...); that have been causing the problem mentioned above, in https://bugzilla.mozilla.org/show_bug.cgi?id=571918#c0
Summary: When clicking on a link (when not using the Default Theme), a new Tab will open with the Title 'Loading...' → When clicking on a link (when using a Persona not the Default Theme), a new Tab will open with the Title 'Loading...'
Version: unspecified → Trunk
To further detail:

It appears that (at least with D2D on) there's a section between two vertical lines that does in fact get updated (it is maybe half the first letter gets updated), but the other part of the tab title does not. Once the tab loses focus (if I switch to another tab), the title does get updated. This only happens when I have a Persona applied.
I also have Persona installed, but only see this bug when I middle-click on a bookmark, not links on a web page. Otherwise, I can entirely confirm comment #4, even with D2D off.
* it does not matter how the new tab is opened (clicking a link, using the addon manager)
* the invalidation/artifact issue reminds me on Bug 522392. maybe the same core bug is being exposed here too?
Status: UNCONFIRMED → NEW
blocking2.0: --- → ?
Ever confirmed: true
Summary: When clicking on a link (when using a Persona not the Default Theme), a new Tab will open with the Title 'Loading...' → title of an opened tab keeps showing "Loading" when using a Persona
Along with this behavior (Loading... staying on the Tab Title), if I Click on the open "New Tab" button and then key a URL (Ex: "pgatour.com") in the Navigation Toolbar and press Enter, "New Tab" remains as the Tab title, until the Focus is changed to a different tab.
(In reply to comment #7)
> Along with this behavior (Loading... staying on the Tab Title), if I Click on
> the open "New Tab" button and then key a URL (Ex: "pgatour.com") in the
> Navigation Toolbar and press Enter, "New Tab" remains as the Tab title, until
> the Focus is changed to a different tab.

It seams with the latest daily, I can't seam to recreate the "New Tab" Tab Title staying on the screen. It now looks the same as "Loading..." for the Title.

Build:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a6pre) Gecko/20100618 Minefield/3.7a6pre ( .NET CLR 3.5.30729) Firefox/3.6.3 ID:20100618040705
Duplicate of this bug: 573221
Component: Tabbed Browser → General
Product: Firefox → Core
QA Contact: tabbed.browser → general
Duplicate of this bug: 573337
Be aware others have been reporting odd New Tab behaviour during the past two days:

"I still have the problem where clicking 'New Tab' (not Ctrl-T) creates a new tab with the text 'New Tab' in a faint gray... Doesn't seem like that's getting fixed"
"It seems very random - at times I get the *proper* black text, and other times I get either the light gray text or none at all..."
"I can reproduce this problem on trunk. Is there anything filed yet covering it? STR are easy, make a new profile and then click the [+] on the tabbar. Alternatively move the mouse pointer to be to the right of the tabbar [+] and then press CTRL+T. Looks like as if the new new-tab animation starts but then firefox sees the mouse is now hovering over the new tab that's being animated and then the colouring gets confused."
(In reply to comment #11)
> Be aware others have been reporting odd New Tab behaviour during the past two
> days:
> 
> "I still have the problem where clicking 'New Tab' (not Ctrl-T) creates a new
> tab with the text 'New Tab' in a faint gray... Doesn't seem like that's getting
> fixed"
> "It seems very random - at times I get the *proper* black text, and other times
> I get either the light gray text or none at all..."
> "I can reproduce this problem on trunk. Is there anything filed yet covering
> it? STR are easy, make a new profile and then click the [+] on the tabbar.
> Alternatively move the mouse pointer to be to the right of the tabbar [+] and
> then press CTRL+T. Looks like as if the new new-tab animation starts but then
> firefox sees the mouse is now hovering over the new tab that's being animated
> and then the colouring gets confused."

This is Bug 573241
Is this bug Windows-only?  I can't seem to reproduce on Linux or Mac...
Keywords: qawanted
(In reply to comment #13)
> Is this bug Windows-only?  I can't seem to reproduce on Linux or Mac...
Reproduce:
Mozilla/5.0 (Windows; U; Windows NT 6.1; WOW64; en-US; rv:1.9.3a6pre) Gecko/20100620 Minefield/3.7a6pre

Not reproduce:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.3a6pre) Gecko/20100621 Minefield/3.7a6pre
OK, so as a core bug, is this a regression?  That is, does applying bug 543206 to older builds also show the problem?
Attached file testcase (obsolete) —
I am not sure whether this testcase expresses a problem definitely,
however, label of toolbarbutton does not repaint properly.

[str]
1.load testcase
2.click "Start0"
3.click "Start1"

[actual]
loading  (at step2)
Finish0 loading (finally)

[expected]
Finish0 (at step2)
Finish0 Finish1(finally)

regression window:
works:
http://hg.mozilla.org/mozilla-central/rev/106dc288fd5f
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1b3pre) Gecko/20081126 Shiretoko/3.1b3pre ID:20081126035913

fails:
http://hg.mozilla.org/mozilla-central/rev/607791c2f989
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1b3pre) Gecko/20081127 Shiretoko/3.1b3pre ID:20081127035619

pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=106dc288fd5f&tochange=607791c2f989
Attached file testcase
Attachment #453705 - Attachment is obsolete: true
Various overflow area stuff landed in there.

Can someone try bisecting to get a better range?
(In reply to comment #18)
> Various overflow area stuff landed in there.
> 
> Can someone try bisecting to get a better range?

When revert to 6d6a178f9132 in local build, then the testcase works.
So, It seems to cause the problem by landing http://hg.mozilla.org/mozilla-central/rev/607791c2f989 
candidate:
Bug 463292 - overflowing text-shadow in XUL labels not fully repainted
Blocks: 463292
Duplicate of this bug: 575613
Duplicate of this bug: 575945
If interesting, I don't get this bug when loading a new tab from the "Home" button, or a link on the webpage. Only when loading from the bookmarks toolbar.
(In reply to comment #22)
> If interesting, I don't get this bug when loading a new tab from the "Home"
> button, or a link on the webpage. Only when loading from the bookmarks toolbar.

Err, the reload, back, forward etc buttons also produce this bug.
Duplicate of this bug: 576184
Duplicate of this bug: 576579
I have also noticed that whatever Title a tab has, sometimes stays on the tab when you load a new web page to it (as long as you have not changed focus off it yet).

Seeing this question (post) in the mozillazine forum this morning (http://forums.mozillazine.org/viewtopic.php?f=23&t=1937639&start=175) is one example of this.

Example steps to recreate (when using a Persona):
1. Press the New Tab button.
2. Without leaving the New Tab, press a URL in your Bookmarks (even the Home button will work).
3. Title remains "New Tab".
4. If you manually key in a location (ex: about:config) before leaving that new tab the Title then changes to "Loading...".
In this attachment the Tab Title should match the Windows Title bar 'iGoogle' (see red circled areas on attachment).
Duplicate of this bug: 577541
WORKAROUND: append the following css to userChrome.css

.tabbrowser-tab:-moz-lwtheme[fadein][selected="true"]{
  text-shadow: 0 0 !important;
}
Duplicate of this bug: 578781
Duplicate of this bug: 579665
blocking2.0: ? → beta3+
Duplicate of this bug: 580851
Roc, is qawanted still valid here?
Whiteboard: [4b2]
No, Alice's testcase is enough. Thanks Alice!!!
Keywords: qawanted
I don't know if it's just me or if others are seeing this too, but it seems like a different bug that landed either in the 2010.07-23 or 2010.07-24 fixed the Tab Title problem.
I double check my userChrome.css and the workaround Alice gave when I first filed this bug, is still commented out.
Even though I have not seen this happen lately in the latest Minefield nightlies, Firefox 4.0 Beta 2 still has this problem.

Mozilla/5.0 (Windows; Windows NT 5.1; rv:2.0b2) Gecko/20100720 Firefox/4.0b2 ( .NET CLR 3.5.30729) Firefox/3.6.6 ID:20100720190347
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=f1bd51cdac68&tochange=0a83bd05d402
Landing of Bug 580221 fixed the problem.
    1.55 -.tabbrowser-tab:-moz-lwtheme[selected="true"] {
    1.56 -  text-shadow: none;
    1.57 -}
Duplicate of this bug: 582617
Dao: so should this now be RESO FIXED by that other bug?
No, it remains a core bug which the default theme currently doesn't trigger anymore.
Default theme + persona? In that case, removing blocking. Renominate if I got that wrong.
blocking2.0: beta3+ → -
It's still a regression bug in painting that can bite at least extension UI; not clear whether it can hit web pages.  If we knew for sure it can't, not blocking might be ok, but as it is seems like we need to at least sort that out.
blocking2.0: - → ?
OK, I'll let roc re-triage, don't think it needs to be beta3+ anymore, though.
Duplicate of this bug: 583399
Duplicate of this bug: 583483
It's still reproducible ?
Because I don't see this anymore, probably retained layers landing fix this.
BernesB, were you testing on the testcase attached to this bug?  Or something else?
Alice's testcase is still valid, nightlies just look fixed using a persona (lwtheme) per comment 38-41.
Duplicate of this bug: 577101
Duplicate of this bug: 585305
Duplicate of this bug: 586503
blocking2.0: ? → -
* the attached Testcase is kind of worthless now (Bug 546857?) testing against an unmodified Nightly Build.

* this Issue is being triggered by just previewing + not applying a Personas (and thus keeping the Standard Theme) untill the next Browser Restart.
(In reply to comment #53)
> * the attached Testcase is kind of worthless now (Bug 546857?) testing against
> an unmodified Nightly Build.
> 
> * this Issue is being triggered by just previewing + not applying a Personas
> (and thus keeping the Standard Theme) untill the next Browser Restart.

FYI,
If you want to load link by click,
Add an entry host:bugzilla.mozilla.org,  type:allowXULXBL, permission:1 to permissions.sqlite

If you want load downloaded xul file,
Add an entry host:"<file>" (without quotation),  type:allowXULXBL, permission:1 to permissions.sqlite
You need to log in before you can comment on or make changes to this bug.