Note: There are a few cases of duplicates in user autocompletion which are being worked on.

Setting window.title is broken

VERIFIED FIXED in M15

Status

()

Core
XUL
P2
blocker
VERIFIED FIXED
18 years ago
9 years ago

People

(Reporter: Alec Flett, Assigned: travis)

Tracking

({polish})

Trunk
polish
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [PDT+])

(Reporter)

Description

18 years ago
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

18 years ago
see bug 13385
(Reporter)

Updated

18 years ago
Depends on: 13385
(Reporter)

Updated

18 years ago
Blocks: 11091
(Reporter)

Comment 2

18 years ago
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...
(Reporter)

Updated

18 years ago
Blocks: 14031
Status: NEW → RESOLVED
Last Resolved: 18 years ago
No longer depends on: 13385
Resolution: --- → DUPLICATE
(Reporter)

Comment 3

18 years ago
This is a dupe of the general case of #13385

*** This bug has been marked as a duplicate of 13385 ***
(Reporter)

Updated

18 years ago
Status: RESOLVED → REOPENED
(Reporter)

Comment 4

18 years ago
crap, I mean to put that in another bug.

Updated

18 years ago
Resolution: DUPLICATE → ---

Updated

18 years ago
Blocks: 14742

Updated

18 years ago
Blocks: 15157

Updated

18 years ago
Summary: setting window.title is broken → [Dogfood] setting window.title is broken

Comment 5

18 years ago
My group is dependent on this bug fix for dogfood (internal URL):

http://scopus/bugsplat/show_bug.cgi?id=363882

Updated

18 years ago
Whiteboard: [PDT-]

Comment 6

18 years ago
You can still work around this for dogfood... PDT-

Updated

18 years ago
Target Milestone: M12

Comment 7

18 years ago
targetting m12, p3

Comment 8

18 years ago
mass-moving all m12 bugs to m13

Comment 9

18 years ago
*** Bug 18405 has been marked as a duplicate of this bug. ***

Comment 10

18 years ago
Alec, how come all the other components can set their window title, but the
mail/news title still says "mozilla"?
(Reporter)

Comment 11

18 years ago
"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

18 years ago
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.

Updated

18 years ago
Whiteboard: [PDT-] → [PDT+]

Comment 13

18 years ago
Need this on dogfood PDT+ since it fix is needed for Bugsplat 3363882 PDT+ bug.

Updated

18 years ago
Target Milestone: M13 → M12

Comment 14

18 years ago
targetting M12

Updated

18 years ago
Whiteboard: [PDT+] → [PDT+] sched 28 Nov

Updated

18 years ago
Whiteboard: [PDT+] sched 28 Nov → sched 28 Nov

Comment 15

18 years ago
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.

Updated

18 years ago
Whiteboard: sched 28 Nov → [PDT-] sched 28 Nov

Comment 16

18 years ago
This isn't a dogfood stopper. Marking PDT-.

Comment 17

18 years ago
spam: changing qa contact from ckritzer -> paulmac for xul bugs

Updated

18 years ago
Priority: P3 → P2
Whiteboard: [PDT-] sched 28 Nov → [PDT-]
Target Milestone: M12 → M13

Comment 18

18 years ago
no time left in m12 for non-PDT bugs. moving to m13,p2

Comment 19

18 years ago
*** Bug 22896 has been marked as a duplicate of this bug. ***

Comment 20

18 years ago
*** Bug 23371 has been marked as a duplicate of this bug. ***

Updated

18 years ago
Status: REOPENED → ASSIGNED
Target Milestone: M13 → M15

Comment 21

18 years ago
Looking for stuff to chuck out past M14. Objections? (Is this really a blocker?)

Comment 22

18 years ago
BULK MOVE: Changing component from XUL to XP Toolkit/Widgets: XUL.  XUL 
component will be deleted.
Component: XUL → XP Toolkit/Widgets: XUL

Comment 23

18 years ago
*** Bug 24775 has been marked as a duplicate of this bug. ***

Updated

18 years ago
Keywords: polish

Comment 24

18 years ago
moving from leftover dogfood to beta1 radar.
Keywords: beta1
Summary: [Dogfood] setting window.title is broken → Setting window.title is broken
Whiteboard: [PDT-]

Comment 25

18 years ago
pdt needs to know difficulty/risk of fix.  Can we get this is in for beta?  Does 
this affect AIM?
(Assignee)

Comment 26

18 years ago
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

18 years ago
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

Comment 28

18 years ago
Putting on PDT+ radar for beta1.
Whiteboard: [PDT+]
(Assignee)

Comment 29

18 years ago
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: 18 years ago18 years ago
Resolution: --- → FIXED

Comment 30

18 years ago
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

Updated

9 years ago
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.