Closed Bug 522392 Opened 15 years ago Closed 7 years ago

having only 1 tab open and navigating between long and short tab titles pages, leave artifact for a brief moment

Categories

(Core :: XUL, defect, P2)

Product:
Core
Component:
XUL
Version:
1.9.2 Branch
Platform:
x86
Windows 7
Type:
defect

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: mozbugz, Assigned: MatsPalmgren_bugz)

References

Details

Attachments

(5 files)

Windows 7, default theme, using lwtheme - tab title text artifact.
27.74 KB, image/jpeg
Details
picture of the described problem
22.73 KB, image/jpeg
Details
Tab bar - some letters left
315.22 KB, image/png
Details
More Proof
32.56 KB, image/jpeg
Details
image of a long title being overwritten by a slightly shorter title with artifact from longer title
55.00 KB, image/png
Details 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a1pre) Gecko/20091014 Minefield/3.7a1pre (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a1pre) Gecko/20091014 Minefield/3.7a1pre (.NET CLR 3.5.30729)

having 1 tab open and navigating back and forth on URLs with long titles, causes the 1st tab to leave artifacts where the close tab icon would be.

I notice this if I open a mozillazine trunk forum thread, and browse to say planet mozilla and click the back and forth buttons I see a brief artifact where the close tab icon would normally be.  

Reproducible: Always

Steps to Reproduce:
1. Open 1 tab
2. Open planet mozilla blogs
3. Now open a mozillazine forum page with longer than tab width title.
4. Click on the back button
5. Click on forward button
6. Repeat steps 4&5
Actual Results:  
text stays where close tab icon would be on the tab bar.  Upon moving mouse away from back/forth navigation bar buttons, tab title refreshes.

Expected Results:  
I should not be seeing the text artifact were the close tab icon is at all.  It appears the close icon is being draw between steps, or the text is not being cleared on back/forth actions.

Screenshot coming up next. This also reminds me of the bug for the awesome bar and titles running longer than the tags area.
cc: dao, this is ui-polish
Component: General → XUL
Product: Firefox → Core
QA Contact: general → xptoolkit.widgets
This looks like bug 519589 changed the artifacting behavior .. because now I no longer see text at all where the close icon would normally be using build from rev:1d5e6291b258
Well, scratch that, turns out if I'm going back and forth between short and long pages, but never leave the navigation bar, I don't run into this case right away, artifacts don't show up, but if I go back to the STR, they are there.
Sometimes i see this in Vista too
Status: UNCONFIRMED → NEW
Ever confirmed: true
happens on Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.2b5) Gecko/20091204 Firefox/3.6b5 ID:20091204143806 too.
Keywords: regression, regressionwindow-wanted
Version: unspecified → 1.9.2 Branch
Confirmed in Fx 3.7a1pre on XP (32bit)
Mozilla/5.0 (Windows; U; Windows NT 5.1; pl-PL; rv:1.9.3a1pre) Gecko/20091219 Minefield/3.7a1pre

Nice will be seeing this bug fixed in release Fx 3.6, cause it happens about 25-50% time when I back to precious site
Flags: wanted1.9.2?
Flags: blocking1.9.2?
i can confirm that too, this artifact also appears if i enter a url with a short title, not only on if i click the forward/back button
and sometimes the place where if you have more than one tab open the close button appears is empty though the site has a tab title --> you can see what i mean in the attached picture

Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.2b5) Gecko/20091204 Firefox/3.6b5 (.NET CLR 3.5.30729)
FWIW, I never see this on Windows 7. Clear STR with the latest beta build would be appreciated.
Flags: wanted1.9.2?
Flags: wanted1.9.2+
Flags: blocking1.9.2?
Flags: blocking1.9.2-
please fix this in 3.6 final, this happens really often and looks unprofessional
so everyone seeing this bug, will think firefox is a really buggy software...

i think this should be blocking 1.9.2 --> i already explained the reasons
(In reply to comment #11)
> FWIW, I never see this on Windows 7. Clear STR with the latest beta build would
> be appreciated.

Freshly tested on installed (removing old Fx, removing all Mozilla & Firefox keys/folders from register/system) Fx3.7a1pre and Fx3.6b6-Portable with default settings, without any addons and still see this bug...

IMO this should be BLOCKER in 3.6 :)
Mike, I haven't had time to really review the STR for Windows 7, but I definitely was seeing this with at least 1 windows OS and don't have access to XP right now and rarely boot into my Vista OS.  I can confirm as I just tried it now in a new window with Win7 that I didn't see it pause/update the tab/title [X] area with the latest trunk. While I don't think Win7 is really immune to this bug, but for sure less affected as I reported it while using Win7.
Alright, I think this only occurs if you use a Persona with the functionality built into the trunk/branch builds. My exact STR are:

1. Open a single tab and visit https://bugzilla.mozilla.org/show_bug.cgi?id=522392
2. Visit http://www.sydonis.com
3. Close the browser.

4. Reopen the browser.
5. Create a new blank tab.
6. Close the blank tab.
7. Hit back, you should now be missing text where the close button would be.

If you reverse the sites in 1 and 2 then you should get the artifact instead of missing text. With those steps I'm going to try and narrow down a regression window, but it'd be nice if someone else could verify that they are indeed using Personas.
http://hg.mozilla.org/mozilla-central/rev/1737ecbfb542 doesn't break and doesn't have personas
http://hg.mozilla.org/mozilla-central/rev/447f60ab191c breaks and has personas

http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=1737ecbfb542&tochange=447f60ab191c

There's a lot of changes in that range, I'll try to narrow if I can find other builds.
Found an hourly.

http://hg.mozilla.org/mozilla-central/rev/d32b4b3c29ac breaks

Which gives this 13 hour range:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=1737ecbfb542&tochange=d32b4b3c29ac

I'm CC'ing Dao again since I think this is personas, hope that's appropriate.
the only bug related to personas in the range roberts posted is 511107 which is quite a big change
Bug 511107 can't be the fundamental cause of this. This is more deeply broken, which is why I moved this to Core:XUl.
Keywords: regression, regressionwindow-wanted
Is there something else I can try? Would trying the Personas extension on previous versions of Firefox be worth anything? Can you at least reproduce it given my STR?
(In reply to comment #21)
> Is there something else I can try? Would trying the Personas extension on
> previous versions of Firefox be worth anything?

The extension might trigger the bug as well, yes.

> Can you at least reproduce it given my STR?

I've seen it a few times.
Maybe this helps

https://bugzilla.mozilla.org/show_bug.cgi?id=536034#c0

"I think buildin Persona is causing this, even without selected theme (default
theme) and with disabled all addons.

Persona 1.4 and nightly build of Persona 1.5-pre
(Personas-dev-1.5x0d200911232116.xpi) didnt have this bug as far I remember."
I don't know how different the extension is from what is implemented in 3.6/Minefield, but here is what I found.

Using 3.0.18pre and all versions of Personas on AMO I could not cause the issue
Using 3.5.8pre and all versions of Personas on AMO I could not cause the issue
Using m-c nightlies prior to 20090904 and all versions of Personas on AMO I could not cause the issue
The 20090904 m-c nightly would not work with the personas extension (?)

Using the 20100108 m-c nightly with Personas 1.5 I could replicate the issue.
Using the 20100108 m-c nightly with Personas 1.4 I could not replicate the issue.

Just to clarify the last bit there, although the m-c nightly had support for lwthemes, the addon manager listed the default theme as being in use, and Personas listed the "Mozilla Firefox" lwtheme as being selected.

I assume that Personas 1.5 now delegates the themeing work to Minefield if it detects that lwthemes are supported. So I don't know if there's a difference between the Personas lwtheme implementation and what exists in Minefield, but maybe that's a place to start looking?

If there's anything else I can try let me know.
I had same issue on ff 3.6 final release.
I tried to uninstall and reinstall Personas extension (Personas Plus 1.5.1) and the problem disappeared. I do not know what happened because the problem appeared in version 1.5.1 and now no.
Sorry the solution that i posted is inconsistent. After 10 minutes the problem returned. 
I noticed that issue doesn't occur in first tab (the tab that opens when firefox startes) but when you open a new tab and close first one.
To reproduce:
1. Open ff
2. open a new tab
3. close first tab
4. open this page
5. go to google.
I forgot it: I use ff 3.6 on WinXP SP3

    
    

    
  
Looks like if you move the mouse over to the artifact, it disappears. 
I also attached a screen-shot.

    
    

    
  
I just wanted to confirm that it happens with me for a long while with all the beta and RC versions, in Windows 7.
Also, pointing with the mouse over it "clears" the mistitle, but indeed that can't be the solution. Trying out thorougly with 3.6 final version in teh present to check it out.

    
    

    
  
Still happening in Firefox 3.6 final release.

    
    

    
  
Thanks for all the confirmations but we do not need any more. We are aware of this issue and have to fix this bug. Thanks.

    
    

    
  
Thank you for your efforts!

    
    

    
  
this bug really sucks. it looks so ugly, can anyone tell me what to do to find the broken code or even to fix it? i would like to help removing this uglyness

    
    

    
  
One workaround I'm using is to display the close button on all tabs even if there is only one tab open. I accomplished this by using some Stylish code I found via Google.

    
    

    
  
(In reply to comment #43)
> One workaround I'm using is to display the close button on all tabs even if
> there is only one tab open. I accomplished this by using some Stylish code I
> found via Google.

Or you could have set browser.tabs.closeWindowWithLastTab = false to get the same thing.  Bug 501714 fixed showing the close button all the time under the perf change; which actually will close the tab.  But this bug is for default behavior of browser.tabs.closeWindowWithLastTab = true and still exists even with bug 501714 fixed.

    
    

    
  
The problem still exists with Firefox 3.6.2. There has gotta be a way to fix the problem.

    
    

    
  

      
      
      
      

        Attached image
          
        More Proof
        — 
      

    


  

    
    

    
  
Still exisiting in 3.6.3

    
    

    
  
(In reply to comment #41)
> this bug really sucks. it looks so ugly, can anyone tell me what to do to find
> the broken code or even to fix it? i would like to help removing this uglyness

If you want to help you may find when this bug firstly started occurring in Fx
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/
download this builds "XXXX-XX-XX-XX-mozilla-central"

    
    

    
  
(In reply to comment #50)

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.3a1pre) Gecko/20090905 Minefield/3.7a1pre (.NET CLR 3.5.30729)

---

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.3a1pre) Gecko/20090904 Minefield/3.7a1pre (.NET CLR 3.5.30729)

the problem started 05 september, it seems this is also the first build which has personas enabled

let me know if there is anything else i can do now

    
    

    
  
Seriously, look at how many duplicates!!! Seriously, the problem was created. Is that freaking hard to fix???

    
    

    
  
I am having the same issue:

Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3

I will note that I am using Personas, as it seems many of the attachments hint at their use or the use of other theme plugins.

    
  

        Attachment #440144 -
        Attachment description: image of a long title being overwritten by a slightly shorter title with artifact from logner title → image of a long title being overwritten by a slightly shorter title with artifact from longer title
blocking2.0: --- → ?

    
    

    
  
(In reply to comment #51)
> (In reply to comment #50)
> 
> Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.3a1pre) Gecko/20090905
> Minefield/3.7a1pre (.NET CLR 3.5.30729)
> 
> ---
> 
> Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.3a1pre) Gecko/20090904
> Minefield/3.7a1pre (.NET CLR 3.5.30729)
> 
> the problem started 05 september, it seems this is also the first build which
> has personas enabled
> 
> let me know if there is anything else i can do now

now we must wait for dev response...

and this should be BLOCKER for upcoming Firefox 4

    
    

    
  
Seriously. Another duplicate. Mozilla fails at this one. Their professionalism goes straight to trash. This has been full of duplicates. This problem needs to be fixed. What is so hard about this?

    
    

    
  
(In reply to comment #60)
> What is so hard about this?

Three things.

One, the Mozilla developers are reading the title of this bug, not the title of any of the dupes, so they're probably confused at what the cause of the problem might be. (The dupes I've seen, as well as the one I filed, are a lot clearer as to the problem.)

Two, until comment #51 the devs didn't have a regression range. I know that Jesse probably hasn't memorized all the changes that have been made to the Javascript engine thanks to his fuzzer, and I know I certainly can't keep track of the changes I make to my company's codebase all in my head. With the exact nightly determined, the developers have narrowed down what could possibly cause this to only one day's worth of commits. (Since that day's worth also includes Personas landing, there's still quite a lot of code to go through.)

Three, this is fundamentally just a cosmetic bug. There are plenty more important things to worry about, for users who are far less impatient.

    
    

    
  
(In reply to comment #61)
> With the exact
> nightly determined, the developers have narrowed down what could possibly cause
> this to only one day's worth of commits. (Since that day's worth also includes
> Personas landing, there's still quite a lot of code to go through.)

The personas landing exposed this bug, it didn't cause it. So that range doesn't help much.

    
    

    
  
(In reply to comment #62)
> (In reply to comment #61)
> > With the exact
> > nightly determined, the developers have narrowed down what could possibly cause
> > this to only one day's worth of commits. (Since that day's worth also includes
> > Personas landing, there's still quite a lot of code to go through.)
> 
> The personas landing exposed this bug, it didn't cause it. So that range
> doesn't help much.

I agree, I think the patch attachment 433922 [details] [diff] [review] in bug 501714 would be a better place to start looking for this as there appears to be code in there that adjusts the tab in tabbrowser.xml/css


(In reply to comment #61)
> One, the Mozilla developers are reading the title of this bug, not the title of
> any of the dupes, so they're probably confused at what the cause of the problem
> might be. (The dupes I've seen, as well as the one I filed, are a lot clearer
> as to the problem.)
> 

Yes, Sometimes dupes are better at explaining bugs...  so yeah, the real problem is refreshing tab title produces an artifact with respect to the close button when only 1 tab is open and perf browser.tabs.closeWindowWithLastTab = true when navigating between web pages, using the back/forward buttons or mousing or hovering over it.

    
    

    
  
(In reply to comment #63)
> 
> I agree, I think the patch attachment 433922 [details] [diff] [review] in bug 501714 would be a better
> place to start looking for this as there appears to be code in there that
> adjusts the tab in tabbrowser.xml/css
> 

meaning the bug itself wasn't the regression, but the patch might give a clue closer to where the problem is.

    
    

    
  
I was noticing lately that I don't notice this bug if I don't have a persona installed with the latest trunk using only the default theme with no lwtheme or personas installed.  As soon as I use a default theme+lwtheme, I see the bug.

    
    

    
  
here is a screenshot of this bug: http://i50.tinypic.com/30cve5z.png
blocking2.0: ? → final+
Priority: -- → P2

    
    

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

    
    

    
  
(In reply to comment #70)
> It's still reproducible ?

I don't think so - testing the most recent nightly.  Possibly fixed now.

(In reply to comment #70)
> Because I don't see this anymore, probably retained layers landing fix this.

I know it wasn't fixed with the initial retain layers landing on 7-15, since it was still broken after that, though maybe a followup fixed it or another bug about invalidation/tab animations/etc took care of it.

Anyone care to confirm?

    
    

    
  
(In reply to comment #70)
> It's still reproducible ?
> Because I don't see this anymore, probably retained layers landing fix this.

I guess this is related to bug 571918. See bug 571918 comment 38 and below for why this might not show up right now and why the bug should nevertheless stay open.

    
  
OS: Windows NT → Windows 7

    
    

    
  
I don't see why it should block 2.0 when it doesn't occur in the
default theme anymore.
blocking2.0: final+ → ---

    
    

    
  
This should be minused, not removed from the blocking list.

    
    

    
  
Comment on attachment 436855 [details]
More Proof

YES!  This is exactly what I'm seeing...JUST cropped up since the last FF update...at least for me.

    
    

    
  
This bug doesn't happen for me for very long time, so I'm pretty sure that it was fixed.
I'm marking this bug as WORKSFORME.
Reopen if you still can reproduce it.
Status: NEW → RESOLVED
Closed: 7 years ago

          status1.9.2:
          ? → ---
Resolution: --- → WORKSFORME

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: