Closed Bug 13807 Opened 25 years ago Closed 25 years ago

Setting window.title is broken

Categories

(Core :: XUL, defect, P2)

Product:
Core
Component:
XUL
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: alecf, Assigned: travis)

References

Details

(Keywords: polish, Whiteboard: [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.
see bug 13385
Depends on: 13385
Blocks: 11091
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...
Blocks: 14031
Status: NEW → RESOLVED
Closed: 25 years ago
No longer depends on: 13385
Resolution: --- → DUPLICATE
This is a dupe of the general case of #13385

*** This bug has been marked as a duplicate of 13385 ***
Status: RESOLVED → REOPENED
crap, I mean to put that in another bug.
Resolution: DUPLICATE → ---
Blocks: 14742
Blocks: 15157
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
Whiteboard: [PDT-]
You can still work around this for dogfood... PDT-
Target Milestone: M12
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.
Whiteboard: [PDT-] → [PDT+]
Need this on dogfood PDT+ since it fix is needed for Bugsplat 3363882 PDT+ bug.
Target Milestone: M13 → M12
targetting M12
Whiteboard: [PDT+] → [PDT+] sched 28 Nov
Whiteboard: [PDT+] sched 28 Nov → sched 28 Nov
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.
Whiteboard: sched 28 Nov → [PDT-] sched 28 Nov
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. ***
Status: REOPENED → ASSIGNED
Target Milestone: M13 → M15
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. ***
Keywords: polish
moving from leftover dogfood to beta1 radar.
Keywords: beta1
Summary: [Dogfood] setting window.title is broken → Setting window.title is broken
Whiteboard: [PDT-]
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.
Whiteboard: [PDT+]
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
Closed: 25 years ago → 25 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.