Last Comment Bug 13807 - Setting window.title is broken
: Setting window.title is broken
: polish
Product: Core
Classification: Components
Component: XUL (show other bugs)
: Trunk
: All All
P2 blocker (vote)
: M15
Assigned To: travis
: Neil Deakin
: 18405 22896 23371 24775 (view as bug list)
Depends on:
Blocks: 11091 14031 14742 15157
  Show dependency treegraph
Reported: 1999-09-14 14:20 PDT by Alec Flett
Modified: 2008-07-31 02:48 PDT (History)
6 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Description User image Alec Flett 1999-09-14 14:20:22 PDT
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.
Comment 1 User image davidm 1999-09-15 00:26:59 PDT
see bug 13385
Comment 2 User image Alec Flett 1999-09-16 12:56:59 PDT
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...
Comment 3 User image Alec Flett 1999-09-16 13:47:59 PDT
This is a dupe of the general case of #13385

*** This bug has been marked as a duplicate of 13385 ***
Comment 4 User image Alec Flett 1999-09-16 13:49:59 PDT
crap, I mean to put that in another bug.
Comment 5 User image Alex Musil 1999-10-21 11:36:59 PDT
My group is dependent on this bug fix for dogfood (internal URL):

Comment 6 User image Jim Roskind 1999-10-21 18:37:59 PDT
You can still work around this for dogfood... PDT-
Comment 7 User image Peter Trudelle 1999-10-21 19:26:59 PDT
targetting m12, p3
Comment 8 User image Peter Trudelle 1999-11-02 15:03:59 PST
mass-moving all m12 bugs to m13
Comment 9 User image Phil Peterson 1999-11-10 09:54:59 PST
*** Bug 18405 has been marked as a duplicate of this bug. ***
Comment 10 User image Phil Peterson 1999-11-10 10:04:59 PST
Alec, how come all the other components can set their window title, but the
mail/news title still says "mozilla"?
Comment 11 User image Alec Flett 1999-11-10 13:50:59 PST
"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".
Comment 12 User image Peter Trudelle 1999-11-10 13:59:59 PST
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
Comment 13 User image leger 1999-11-10 17:02:59 PST
Need this on dogfood PDT+ since it fix is needed for Bugsplat 3363882 PDT+ bug.
Comment 14 User image Peter Trudelle 1999-11-10 17:18:59 PST
targetting M12
Comment 15 User image leger 1999-11-17 06:42:59 PST
Correct Bugsplat # which this bug is dependant on is:

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.
Comment 16 User image rickg 1999-11-18 17:13:59 PST
This isn't a dogfood stopper. Marking PDT-.
Comment 17 User image Paul MacQuiddy 1999-12-04 22:13:59 PST
spam: changing qa contact from ckritzer -> paulmac for xul bugs
Comment 18 User image Peter Trudelle 1999-12-06 18:03:59 PST
no time left in m12 for non-PDT bugs. moving to m13,p2
Comment 19 User image Phil Peterson 2000-01-06 14:47:59 PST
*** Bug 22896 has been marked as a duplicate of this bug. ***
Comment 20 User image lchiang 2000-01-07 16:48:59 PST
*** Bug 23371 has been marked as a duplicate of this bug. ***
Comment 21 User image Dan M 2000-01-10 19:38:59 PST
Looking for stuff to chuck out past M14. Objections? (Is this really a blocker?)
Comment 22 User image leger 2000-01-20 18:57:39 PST
BULK MOVE: Changing component from XUL to XP Toolkit/Widgets: XUL.  XUL 
component will be deleted.
Comment 23 User image Phil Peterson 2000-01-24 12:05:47 PST
*** Bug 24775 has been marked as a duplicate of this bug. ***
Comment 24 User image Peter Trudelle 2000-01-26 15:16:51 PST
moving from leftover dogfood to beta1 radar.
Comment 25 User image leger 2000-01-27 16:55:38 PST
pdt needs to know difficulty/risk of fix.  Can we get this is in for beta?  Does 
this affect AIM?
Comment 26 User image travis 2000-01-27 18:06:28 PST
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.
Comment 27 User image Dan M 2000-01-27 18:20:43 PST
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.
Comment 28 User image leger 2000-01-28 18:01:54 PST
Putting on PDT+ radar for beta1.
Comment 29 User image travis 2000-01-29 23:56:58 PST
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".
Comment 30 User image Paul MacQuiddy 2000-02-04 22:45:26 PST
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.

Note You need to log in before you can comment on or make changes to this bug.