Closed Bug 454949 Opened 13 years ago Closed 13 years ago

On reload Current Build ID disappears from the title bar (Nightly Tester Tools thing)

Categories

(Firefox :: Tabbed Browser, defect)

x86
Windows XP
defect
Not set
normal

Tracking

()

RESOLVED FIXED
Firefox 3.1b2

People

(Reporter: martijn.martijn, Assigned: mossop)

References

(Depends on 1 open bug)

Details

(Keywords: regression)

Attachments

(1 file, 1 obsolete file)

To reproduce:
- Install Nightly Tester Tools: https://addons.mozilla.org/en-US/firefox/addon/6543
- Visit a web page, notice the title in the title bar with the Current Build ID displayed (something that NTT magically adds)
- Reload the web page

Actual result:
The Current Build ID has disappeared from the title bar. It should have stayed.

Not sure how NTT does add the Build ID to the title bar, but since this regressed when bug 118704 got fixed, I suspect this might be a valid bug.
Dave might know how NTT adds the Build ID to the title bar.
I'm not sure just what part of bug 118704 broke this, but here is what is happening:

1. During page load the title of the new document is detected, NotifyPossibleTitleChange is called for the content document.
2. DoNotifyPossibleTitleChange calls out to nsContentTreeOwner::SetTitle which sets a window title based on the content title and attributes in the XUL root node.
3. DoNotifyPossibleTitleChange dispatches DOMTitleChanged.
4. tabbrowser.xml catches this, calls updateTitlebar which sets the title attribute on the XUL root node.
5. Changing the title attribute fires NotifyPossibleTitleChange for the chrome document which eventually sets the window title.

Now during the reload:

1. During page load the same title for the document is detected, NotifyPossibleTitleChange is called for the content document.
2. DoNotifyPossibleTitleChange calls out to nsContentTreeOwner::SetTitle which sets a window title based on the content title and attributes in the XUL root node, clobbering whatever title tabbrowser.xml set last time.
3. DoNotifyPossibleTitleChange dispatches DOMTitleChanged.
4. tabbrowser.xml catches this, calls updateTitlebar which sets the title attribute on the XUL root node.
5. Since the title attribute is the same as last time, the title attribute isn't actually modified, so NotifyPossibleTitleChange is never called for the chrome document.
Attached patch patch rev 1 (obsolete) — Splinter Review
So here is what I figure we should do. If the chrome window has a title attribute then a change in the content window shouldn't be updating the title of the chrome window at all. This way tabbrowser is able to keep the title up to date without nsContentTreeOwner changing things under it.
Assignee: nobody → dtownsend
Status: NEW → ASSIGNED
Attachment #341768 - Flags: superreview?(jst)
Attachment #341768 - Flags: review?(jst)
Attached patch patch rev 2 -wSplinter Review
Scrub that, we're being silly in the frontend.
Attachment #341768 - Attachment is obsolete: true
Attachment #345712 - Flags: review?(mconnor)
Attachment #341768 - Flags: superreview?(jst)
Attachment #341768 - Flags: review?(jst)
Attachment #345712 - Attachment is patch: true
Attachment #345712 - Attachment mime type: application/octet-stream → text/plain
Comment on attachment 345712 [details] [diff] [review]
patch rev 2 -w

boom.
Attachment #345712 - Flags: review?(mconnor) → review+
Component: DOM: Core & HTML → Tabbed Browser
Product: Core → Firefox
QA Contact: general → tabbed.browser
Pushed: http://hg.mozilla.org/mozilla-central/rev/087c6fa28ecb
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 3.1b2
Blocks: 462997
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b2pre) Gecko/20081104 Minefield/3.1b2pre ID:20081104012825

ID disappears while Private Browsing mode.
(In reply to comment #6)
> Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b2pre) Gecko/20081104
> Minefield/3.1b2pre ID:20081104012825
> 
> ID disappears while Private Browsing mode.

Not a Firefox bug
Depends on: 463253
Depends on: 510809
You need to log in before you can comment on or make changes to this bug.