if I use window.title to set the title of my XUL window, the new title flashes onto the titlebar of the window, and then goes away (it's cleared out, the window has no title) If I set the "titlemodifier" attribute on the window, then the title flashes onto the window and then the title becomes whatever is in titlemodifier. This worked on Friday, Sept 10th. It wasn't working on monday's build. this is preventing mail/news from setting the title of the window.
see bug 13385
I'm not setting it from the onload= handler. I'm setting it on an event handler, when an item in the folder pane is clicked. Please open messenger and try clicking on mail folders...
This is a dupe of the general case of #13385 *** This bug has been marked as a duplicate of 13385 ***
crap, I mean to put that in another bug.
Summary: setting window.title is broken → [Dogfood] setting window.title is broken
My group is dependent on this bug fix for dogfood (internal URL): http://scopus/bugsplat/show_bug.cgi?id=363882
You can still work around this for dogfood... PDT-
targetting m12, p3
mass-moving all m12 bugs to m13
*** Bug 18405 has been marked as a duplicate of this bug. ***
Alec, how come all the other components can set their window title, but the mail/news title still says "mozilla"?
"Mozilla" comes from the message's IFRAME. The problem is, when we switch folders, we load about:blank into the message IFRAME, which has no title.. so the title of the message IFRAME gets set to "". The problem is that the webshell is propagating this title change up to the main window, which it should not. That's the bug. When it gets there, it does some magic to take the page title ("") and the product name ("Mozilla") and make a pretty title, resulting in the window's title, "Mozilla".
Why is the severity of this bug set to blocker? That is supposed to be reserved for when a developer cannot make any progress, and should be treated like the old P0 category. Please use dependencies to indicate another bug requires this fix.
Need this on dogfood PDT+ since it fix is needed for Bugsplat 3363882 PDT+ bug.
Correct Bugsplat # which this bug is dependant on is: http://scopus/bugsplat/show_bug.cgi?id=363882 Per trudelle email (needs re-review by PDT): "Respectfully disagree that this level of function is needed for use as dogfood, including multiple concurrent IM sessions." Removing PDT+ for re-eval.
This isn't a dogfood stopper. Marking PDT-.
spam: changing qa contact from ckritzer -> paulmac for xul bugs
Priority: P3 → P2
Whiteboard: [PDT-] sched 28 Nov → [PDT-]
Target Milestone: M12 → M13
no time left in m12 for non-PDT bugs. moving to m13,p2
*** Bug 22896 has been marked as a duplicate of this bug. ***
*** Bug 23371 has been marked as a duplicate of this bug. ***
Looking for stuff to chuck out past M14. Objections? (Is this really a blocker?)
BULK MOVE: Changing component from XUL to XP Toolkit/Widgets: XUL. XUL component will be deleted.
Component: XUL → XP Toolkit/Widgets: XUL
*** Bug 24775 has been marked as a duplicate of this bug. ***
moving from leftover dogfood to beta1 radar.
Summary: [Dogfood] setting window.title is broken → Setting window.title is broken
pdt needs to know difficulty/risk of fix. Can we get this is in for beta? Does this affect AIM?
I have some changes in my tree that will likely fix this in the next day or so. If not I'll take a look at debugging it. Dan flip it to me if you like.
Travis has been threatening for a fix for this bug to fall out of his work. I'm bumping it over to him. Let me know if the solution doesn't just fall out.
Assignee: danm → travis
Status: ASSIGNED → NEW
Putting on PDT+ radar for beta1.
Ok, this should be fixed now. There were a few problems. First there wasn't really infrastructure setup to distinguish between the different people (chrome, content, and primary content areas) setting the title. I added this infrastructure. Now only chrome and primary content areas can set the title of the outside window, others are ignored. This gets around multiple content areas fighting for the window title. I then made a change to messenger.xul to make it's content area of type "content" rather than "content-primary".
Status: NEW → RESOLVED
Last Resolved: 19 years ago → 19 years ago
Resolution: --- → FIXED
This looks fixed 2/4, at least how it manifested itself in mail. Individual aim sessions still come up as 'untitled'. Travis is looking at that at and will be written up as separate bug.
Status: RESOLVED → VERIFIED
Component: XP Toolkit/Widgets: XUL → XUL
QA Contact: paulmac → xptoolkit.widgets
You need to log in before you can comment on or make changes to this bug.