Closed Bug 50682 Opened 24 years ago Closed 24 years ago

Cannot change the title of a window

Categories

(Core :: XUL, defect, P2)

Product:
Core
Component:
XUL
Platform:
Other
Linux
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: ji, Assigned: adamlock)

References

Details

(Keywords: platform-parity, regression, Whiteboard: [nsbeta3-][PDTP2][rtm++])

Attachments

(1 file)

This patch puts back the old behaviour. Comments please.
3.28 KB, patch
Details | Diff | Splinter Review 
***obseverd with linux 2000082906 build *****

On the Mail's main window, when a mail is selected, the subject of the mail will
show
as part of the window title. But now the window only has "Mail" as the window
title.
It used to be working even with yesterday's build. (2000082811 linux)

Steps to reproduce:
1. Launch Mail.
2. Select any mail.
You'll see the mail window title does't reflect the subject of the mail.
A compose window doesn't get the subject as window title, either.
Keywords: nsbeta3, regression
QA Contact: lchiang → laurel
Same problem with Mac & Windows. Seems to be a generic problem, you cannot change anymore the title of a window 

dynamically.



window.title = xxxx doesn't work anymore. Reassign to xptoolkit
Assignee: putterman → waterson
Component: Mail Window Front End → XP Miscellany
OS: Linux → All
Product: MailNews → Browser
QA Contact: laurel → brendan
Hardware: PC → All
Summary: Mail subject doesn't show as the mail window title → Cannot change the title of a window
cc'ing adamlock (who's been working with window.title lately) and danm ('the 
window guy')
Component: XP Miscellany → XP Toolkit/Widgets
QA Contact: brendan → jrgm
really reassign to xptoolkit.
Assignee: waterson → trudelle
->danm, cc pav (who fixed related bug 41786 last week).  Is this even our bug?
It seems like if you can set the title at all (e.g., "Mail"), then the toolkit
is working.  Browser has no trouble setting title today.
Assignee: trudelle → danm
This is mine. I have a fix ready.
Assignee: danm → vidur
Note to pdt if they read this:  mail would like this fixed - otherwise, if a
window is minimized or under the tasks menu, it will be hard to distinguish
between various open mail windows.
Keywords: mailtrack
I have a question here - is "window.title" meant to set and get the contained 
document title? It's unclear to me from looking at the interface or the 
implementation if this is the intent.

Bug 41984 is complaining that window.title does not return the document title, 
so I have submitted a patch that maps the global window's SetTitle/GetTitle 
implementations onto the primary content docshell's SetTitle/GetTitle. Is this 
right?

What happens if there is no primary content document, or if you want to set the 
title on the window but not the document.
Fixed on 8/30/2000.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Thanks
*** Bug 50820 has been marked as a duplicate of this bug. ***
*** Bug 50802 has been marked as a duplicate of this bug. ***
to QA: pls verify the duplicate bugs also, if possible.  Thanks.
Reopening this bug since problems are back again based on verification for 
09-01-08-M18 commercial builds for all the platforms
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
*** Bug 51573 has been marked as a duplicate of this bug. ***
Pls triage this soon.  This is pretty visible in mail and really hinders 
usability when there are a lot of windows open (i.e. windows minimized so that 
there is no distinguishing items to tell them apart)
Severity: normal → major
In the absence of any feedback to my previous questions on this bug, I put the 
checkin for bug 41984.

I changed window.title so it maps onto the primary content document's title 
property. Perhaps the mail window has no primary content document? The old 
mechanism although broken may have worked in such circumstances since it 
incorrectly mapped the title property onto the topmost chrome document so that 
once the title was set to something, you could get that value back again.

Perhaps when the nsGlobalWindow class cannot get a primary content document it 
should set and get its title from a private member string?
This affects AIM in NS6 as well , in both IM compose session windows, and the 
buddy list itself. You can't see who you're having an IM session with (for IM 
compose) or who you're currently logged in as (on standalone IM Buddy List)
window.title is not a DOM Level 0 or 1 property, so its semantics are completely 
up to the toolkit guys. I've done my part to make sure that 
GlobalWindowImpl::SetTitle is called - I don't own the implementation. Adam, 
since you touched the implementation last, you're it.
Assignee: vidur → adamlock
Status: REOPENED → NEW
Okay, how about this:

If there is a primary content document then window.title maps onto that. If 
there is no primary content document, then window.title sets and gets a 
private member variable in nsGlobalWindow.

This should ensure that window.title will return whatever it was set to *and* 
fix it's behaviour with drag and drop shortcuts.
*** Bug 52687 has been marked as a duplicate of this bug. ***
Blocks: 51631
adding the dependency on our security bug because window titles stopped showing
up in the password dialog recently.

dependent bug is nsbeta3+ (but P3).  mscott- should the other bug be a higher
priority?
Yes it should be higher priority.
No longer blocks: 51631
Blocks: 51631
Mail, New Folder window is also affected.
Jud, can we get an nsbeta3+, P2 on this based on the blocked bug's priority?
per dependence tree.
Whiteboard: [nsbeta3+]
Jud, did you mean to agree with selmer's P2 assessment of this bug?  If so, pls 
mark P2.
Priority: P3 → P2
PDT agrees P2, but mainly because it's a regression on something which used to
work. Otherwise, it would probably be P3.
Whiteboard: [nsbeta3+] → [nsbeta3+][PDTP2]
adam, these changes appear to drop docshell walking from the picture. Can you
please provide some explaination as to why that's desirable?

Jud, the old behaviour (the one I checked in last) mapped window.title onto 
document.title. This is not what is required so the patch I provided today, 
stores the title in a member variable. When someone set's the title, the code 
stores the new title and locates the nsIBaseWindow representing the frame and 
calls SetTitle on that. There is no longer any connection between the window 
title and the document title.
nsbeta3++ on the strength of the mail server password spoofing bug (dependent 
bug 51631). Otherwise, it could probably wait for RTM. Please go quickly into 
the branch since time is short.
Whiteboard: [nsbeta3+][PDTP2] → [nsbeta3++][PDTP2]
Talked this over with jar and we think we can live without this in PR3 (it's 
just a beta, and our password-spoofing vulnerability is similar to 4.x). Marking 
nsbeta3- but adding rtm nomination. We still think this is important to fix for 
RTM.
Whiteboard: [nsbeta3++][PDTP2] → [nsbeta3-][PDTP2]
Adding rtm keyword.
Keywords: rtm
Adding my vote for rtm++.  Adam can you get your manager to mark this one rtm+ so it 
will show up on the PDT radar?
Jud, can you mark this rtm+ ?
*** Bug 52616 has been marked as a duplicate of this bug. ***
*** Bug 53536 has been marked as a duplicate of this bug. ***
Whiteboard: [nsbeta3-][PDTP2] → [nsbeta3-][PDTP2][rtm+]
Is the patch from 9-21 still current?
Has this been super reviewed?
The patch is current. It was super-reviewed and approved by Scott MacGregor
Status: NEW → ASSIGNED
PDT marking [rtm++]
Whiteboard: [nsbeta3-][PDTP2][rtm+] → [nsbeta3-][PDTP2][rtm++]
The fix is now checked into the beta 3 branch and the trunk.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED
Does jst have a similar bug?
Yup, I have a similar bug, I'll dupe that bug once I run into it again...

*** Bug 51449 has been marked as a duplicate of this bug. ***
I still see this on the Linux branch 2000-10-04-09MN6 

(fixed on win32 2000-010-04-09MN6 and Mac 2000-10-04-11MN6)
Reopening and setting keyword for platform parity.
Status: RESOLVED → REOPENED
Keywords: pp
OS: All → Linux
Hardware: All → Other
Resolution: FIXED → ---
Status: REOPENED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED
I checked this in todays Linux  branch also  2000-10-05-09MN6 and it looks 
ok...resolving and verifying. Sorry for the spam!


setting verified
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: