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

Status: RESOLVED FIXED

(Firefox :: Tabbed Browser, defect)

Description

[Martijn Wargers (dead)]

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.

Comment 1

[Dave Townsend [:mossop]]

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.

Comment 2

[Dave Townsend [:mossop]]

Attachment: patch rev 1

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.

Comment 3

[Dave Townsend [:mossop]]

Attachment: patch rev 2 -w

Scrub that, we're being silly in the frontend.

Comment 4

[Mike Connor [:mconnor]]

Comment on attachment 345712 [details] [diff] [review]
patch rev 2 -w

boom.

Comment 5

[Dave Townsend [:mossop]]

Pushed: http://hg.mozilla.org/mozilla-central/rev/087c6fa28ecb

Comment 6

[pal-moz]

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.

Comment 7

[Dave Townsend [:mossop]]

(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