bugzilla.mozilla.org has resumed normal operation. Attachments prior to 2014 will be unavailable for a few days. This is tracked in Bug 1475801.
Please report any other irregularities here.

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

RESOLVED FIXED in Firefox 3.1b2

Status

()

Firefox
Tabbed Browser
RESOLVED FIXED
10 years ago
9 years ago

People

(Reporter: Martijn Wargers (zombie), Assigned: mossop)

Tracking

(Depends on: 1 bug, {regression})

Trunk
Firefox 3.1b2
x86
Windows XP
regression
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

10 years ago
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.
(Assignee)

Comment 1

10 years ago
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.
(Assignee)

Comment 2

10 years ago
Created attachment 341768 [details] [diff] [review]
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.
Assignee: nobody → dtownsend
Status: NEW → ASSIGNED
Attachment #341768 - Flags: superreview?(jst)
Attachment #341768 - Flags: review?(jst)
(Assignee)

Comment 3

10 years ago
Created attachment 345712 [details] [diff] [review]
patch rev 2 -w

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)
(Assignee)

Updated

10 years ago
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+
(Assignee)

Updated

10 years ago
Component: DOM: Core & HTML → Tabbed Browser
Product: Core → Firefox
QA Contact: general → tabbed.browser
(Assignee)

Comment 5

10 years ago
Pushed: http://hg.mozilla.org/mozilla-central/rev/087c6fa28ecb
Status: ASSIGNED → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 3.1b2

Updated

10 years ago
Blocks: 462997

Comment 6

10 years ago
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.
(Assignee)

Comment 7

10 years ago
(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

Updated

10 years ago
Depends on: 463253

Updated

9 years ago
Depends on: 510809
You need to log in before you can comment on or make changes to this bug.