Title attribute of a window is not updated in nsXULWindow::SetTitle

RESOLVED FIXED in mozilla13

Status

()

Core
XUL
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: darktrojan, Assigned: darktrojan)

Tracking

Trunk
mozilla13
Points:
---
Bug Flags:
in-testsuite +
in-litmus -

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 3 obsolete attachments)

(Assignee)

Description

5 years ago
When a window's title is update by calling SetTitle, the DOM's title does not change. For example, in a view source window, the document element's title attribute is always "Nightly".

I've got a patch on Try now.
(Assignee)

Comment 1

5 years ago
Created attachment 581890 [details] [diff] [review]
patch

Appears to have made it through try without breaking anything, although only Linux64 opt has finished.
Attachment #581890 - Flags: review?(bzbarsky)
Comment on attachment 581890 [details] [diff] [review]
patch

Hmm.  I'm not sure what the right behavior is here.  Neil?
Attachment #581890 - Flags: review?(bzbarsky) → review?(neil)
(Assignee)

Comment 3

5 years ago
Created attachment 581911 [details] [diff] [review]
patch v2

Gah, forgot about the OS X quirk.
Attachment #581890 - Attachment is obsolete: true
Attachment #581890 - Flags: review?(neil)
Attachment #581911 - Flags: review?(neil)

Comment 4

5 years ago
Comment on attachment 581911 [details] [diff] [review]
patch v2

Sorry, but nsXULWindow::SetTitle is (eventually) how setting a XUL window element's title attribute updates the window's title, so it's fortunate that you were saved from an infinite loop.

If you really want the source window's chrome document to have the same title as the window, you need to find the code that's setting the window's title directly and change it to set the document's title instead. (And not by setting some random attribute either.)

And then SeaMonkey can remove its title setting hack in its tabbrowser.
Attachment #581911 - Flags: review?(neil) → review-
(Assignee)

Comment 5

5 years ago
Created attachment 582785 [details] [diff] [review]
patch v3

Is this more like it?
Attachment #581911 - Attachment is obsolete: true
Attachment #582785 - Flags: review?(neil)

Comment 6

5 years ago
(In reply to comment #4)
> And then SeaMonkey can remove its title setting hack in its tabbrowser.
Which this patch will in fact break...

Comment 7

5 years ago
(In reply to comment #6)
> (In reply to comment #4)
> > And then SeaMonkey can remove its title setting hack in its tabbrowser.
> Which this patch will in fact break...
Quite badly, in fact :-(

Comment 8

5 years ago
(In reply to comment #7)
> (In reply to comment #6)
> > (In reply to comment #4)
> > > And then SeaMonkey can remove its title setting hack in its tabbrowser.
> > Which this patch will in fact break...
> Quite badly, in fact :-(
So, what happens is that this call to SetTitle is asynchronous because it happens at an unsafe time. The subsequent call in SeaMonkey's tabbrowser to set the XUL window title is still synchronous, so it gets clobbered by the asynchronous title update that this patch generates. Fixing tabbrowser to set the document title will simply coalesce the asynchronous title updates.

Comment 9

5 years ago
(In reply to comment #8)
> So, what happens is that this call to SetTitle is asynchronous because it
> happens at an unsafe time.
Actually that's not true either. Calls to nsXULWindow::SetTitle synchronously update the title (but there's no way of knowing what it is set to, except by the user looking at the screen). Calls to nsDocument::SetTitle synchronously update its title, but then the chrome/content tree owner gets notified asynchronously, and then a DOM title changed event is also fired. The chrome tree owner simply updates the window title, while the content tree owner calls through into this code to set the chrome document's title.
Comment on attachment 582785 [details] [diff] [review]
patch v3

r=me if you give me a chance to fix SeaMonkey when you check this in.
Attachment #582785 - Flags: review?(neil) → review+
Comment on attachment 582785 [details] [diff] [review]
patch v3

Review of attachment 582785 [details] [diff] [review]:
-----------------------------------------------------------------

::: toolkit/components/viewsource/test/browser/browser_bug699356.js
@@ +10,5 @@
>      let gBrowser = aWindow.gBrowser;
>  
>      is(gBrowser.contentDocument.title, source, "Correct document title");
> +    is(aWindow.document.documentElement.getAttribute("title"),
> +      "Source of: " + source + ("nsILocalFileMac" in Components.interfaces ? "" : " - Nightly"),

Isn't "Nightly" Firefox specific?

I suggest code (taken from bug 729474 patch Av1) using indexOf() like
+        isnot(title.indexOf(aEvent.accessible.name), -1,
+              "Window title contains the name of active tab document" +
+              " (Is '" + aEvent.accessible.name + "' in '" + title + "'?)");
Blocks: 729474
(Assignee)

Comment 12

5 years ago
Created attachment 600323 [details] [diff] [review]
patch v4

This is more like it. Tested it on Try.
Attachment #582785 - Attachment is obsolete: true
(Assignee)

Comment 13

5 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/bb48e7c6aef1
Flags: in-testsuite+
Flags: in-litmus-
Target Milestone: --- → mozilla13
https://hg.mozilla.org/mozilla-central/rev/bb48e7c6aef1
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
(In reply to neil@parkwaycc.co.uk from comment #10)
> r=me if you give me a chance to fix SeaMonkey when you check this in.

Two questions:
1. where (bug #) will that happen?
2. will this bug fix finally fix the nasty bug where every browser window in DOMI is called "SeaMonkey"? I thought it was somehow impossible to fix, but maybe this bug made the difference.
I'll answer them myself...

(In reply to Jens Hatlak (:InvisibleSmiley) from comment #15)
> Two questions:
> 1. where (bug #) will that happen?

Already happened, and this bug was referenced:
http://hg.mozilla.org/comm-central/rev/61a16304321b

> 2. will this bug fix finally fix the nasty bug where every browser window in
> DOMI is called "SeaMonkey"?

Yes, this bug fixed that! :-)
(In reply to Jens Hatlak (:InvisibleSmiley) from comment #16)
> http://hg.mozilla.org/comm-central/rev/61a16304321b

V.Fixed wrt SeaMonkey part only, per bug 729474 comment 7 :-)
You need to log in before you can comment on or make changes to this bug.