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

Status: NEW

(Firefox :: Theme, defect)

Description

[Ken]

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.

Comment 1

[Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)]

Attachment: ScreenShot

Conformed on
Mozilla/5.0 (Windows; U; Windows NT 5.1; pl-PL; rv:1.9.3a6pre) Gecko/20100614 Minefield/3.7a6pre

Comment 2

[Ken]

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

Comment 3

[Alice0775 White]

pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=7d3e81dd1018&tochange=33ff230a5b78

Comment 4

[Mike]

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.

Comment 5

[Sid]

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.

Comment 6

[(mostly gone) XtC4UaLL [:xtc4uall]]

* 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?

Comment 7

[Ken]

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.

Comment 8

[Ken]

(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

Comment 11

[Peter Pennington]

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

Comment 12

[Alice0775 White]

(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

Comment 13

[Boris Zbarsky [:bzbarsky]]

Is this bug Windows-only?  I can't seem to reproduce on Linux or Mac...

Comment 14

[Alice0775 White]

(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

Comment 15

[Boris Zbarsky [:bzbarsky]]

OK, so as a core bug, is this a regression?  That is, does applying bug 543206 to older builds also show the problem?

Comment 16

[Alice0775 White]

Attachment: testcase

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

Comment 17

[Alice0775 White]

Attachment: testcase

Comment 18

[Boris Zbarsky [:bzbarsky]]

Various overflow area stuff landed in there.

Can someone try bisecting to get a better range?

Comment 19

[Alice0775 White]

(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

Comment 22

[Joren Guillaume]

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.

Comment 23

[Joren Guillaume]

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

Comment 26

[Ken]

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

Comment 27

[Ken]

Attachment: Example of Tab Title remaining something other than "Loading"

In this attachment the Tab Title should match the Windows Title bar 'iGoogle' (see red circled areas on attachment).

Comment 30

[Alice0775 White]

WORKAROUND: append the following css to userChrome.css

.tabbrowser-tab:-moz-lwtheme[fadein][selected="true"]{
  text-shadow: 0 0 !important;
}

Comment 34

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Roc, is qawanted still valid here?

Comment 35

[Robert O'Callahan (:roc) (email my personal email if necessary)]

No, Alice's testcase is enough. Thanks Alice!!!

Comment 36

[Ken]

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.

Comment 37

[Ken]

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

Comment 38

[Alice0775 White]

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

Comment 40

[Mike Beltzner [:beltzner, not reading bugmail]]

Dao: so should this now be RESO FIXED by that other bug?

Comment 41

[Dão Gottwald [:dao]]

No, it remains a core bug which the default theme currently doesn't trigger anymore.

Comment 42

[Mike Beltzner [:beltzner, not reading bugmail]]

Default theme + persona? In that case, removing blocking. Renominate if I got that wrong.

Comment 43

[Boris Zbarsky [:bzbarsky]]

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.

Comment 44

[Mike Beltzner [:beltzner, not reading bugmail]]

OK, I'll let roc re-triage, don't think it needs to be beta3+ anymore, though.

Comment 47

[Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)]

It's still reproducible ?
Because I don't see this anymore, probably retained layers landing fix this.

Comment 48

[Boris Zbarsky [:bzbarsky]]

BernesB, were you testing on the testcase attached to this bug?  Or something else?

Comment 49

[[not reading bugmail]]

Alice's testcase is still valid, nightlies just look fixed using a persona (lwtheme) per comment 38-41.

Comment 53

[(mostly gone) XtC4UaLL [:xtc4uall]]

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

Comment 54

[Alice0775 White]

(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

Comment 55

[BugBot [:suhaib / :marco/ :calixte]]

The severity field for this bug is relatively low, S3. However, the bug has 17 duplicates.
:jstutte, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Comment 56

[Jens Stutte [:jstutte]]

Assuming that themes live in Firefox, moving to triage there (though it is highly likely that this is long gone).