If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Internet shortcut titles are empty




Document Navigation
18 years ago
17 years ago


(Reporter: Mike Pinkerton (not reading bugmail), Assigned: Adam Lock)




Firefox Tracking Flags

(Not tracked)


(Whiteboard: [nsbeta3-][PDTP2][rtm-])


(3 attachments)



18 years ago
when dragging the proxy icon to the desktop, we need to get the window title to 
put in the filename. navigatorDD.js line 321 accesses |window.title| and it is 
the empty string.

Stepping into nsGlobalWindow::GetProperty() shows we are getting a docShell and 
asking for its title, but nsDocShell::GetTitle() returns to us the empty string.

I put a breakpoint in nsDocShell::SetTitle() and reloaded the page. The docShell 
where the window is set is a different docShell from the one we access using the 
|window| object.


18 years ago
Keywords: nsbeta3


18 years ago
Blocks: 41985

Comment 1

18 years ago
"TEMP URL FILENAME" and the IE icon appear for me when dragging to the desktop

Comment 2

18 years ago
guess that TEMP URL FILENAME text is just a placeholder --> 

Comment 3

18 years ago
i haven't checked in the code that uses window.title yet, and in fact, it will be 
commented out when i do.

Comment 4

18 years ago
The docshell only returns the string previously set through a call to SetTitle. 
Who is supposed to call this?


18 years ago
Keywords: embed

Comment 5

17 years ago
Adding "correctness" keyword.  We need this fixed for beta 3.
Keywords: correctness


17 years ago
Whiteboard: [nsbeta3+]


17 years ago
Target Milestone: --- → M18
what's the status on this? 

vidur, I mentioned this bug to hyatt and he said you might know something about 

Comment 7

17 years ago
It looks like the content docshell's title is being correctly set when the 
document loads, but the nsGlobalWindow.cpp code is asking for the wrong docshell 
for its title. The global window is asking the topmost chrome docshell 
for a title when it should be asking the primary content docshell. Working on a 

Comment 8

17 years ago
Created attachment 13622 [details] [diff] [review]
Global window gets and sets title from/to primary doc shell

Comment 9

17 years ago
Review and approval please.

Once this patch is checked in, navigatorDD.js will needs to be fixed to remove 
the temporary hack around this problem that it contains.
Adam, I'm sorry to say this, but the title code in nsGlobalWindow.cpp changed
dramatically today, you're gonna haveto update (be carefull, there will be merge
conflicts) and create a new diff...

Comment 11

17 years ago
Created attachment 13679 [details] [diff] [review]
Here's the patch updated for the most recent changes. Review please
I say the patch looks good to me, r=jst

Comment 13

17 years ago
Can I just clarify before I check in that this patch is doing the correct thing? 
I am mapping window.title property onto the primary content document's title 
property. If there is no primary content document, then window.title will return 
an empty string.

Comment 14

17 years ago
Changes checked in.
Last Resolved: 17 years ago
Resolution: --- → FIXED

Comment 15

17 years ago
adamlock:backing out your change fixes bug 51569 (tested on win32) which is also
window titles are empty.
Resolution: FIXED → ---

Comment 16

17 years ago
*** Bug 51569 has been marked as a duplicate of this bug. ***

Comment 17

17 years ago
window.title is, I believe, intended to refer to the top-level window's title. 
The fact that this maps to the top-level content document's title element is 
incidental. I would assume that window.title should be "Netscape" (or whatever 
our default window title is) if the top-level content document doesn't have a 
title. Similarly, modifying the window.title property should not change the 
top-level content document's title - it shoud merely change the value appearing 
in the title bar.

Comment 18

17 years ago
*** Bug 52484 has been marked as a duplicate of this bug. ***


17 years ago
Priority: P3 → P2

Comment 19

17 years ago
PDT agrees P2
Whiteboard: [nsbeta3+] → [nsbeta3+][PDTP2]

Comment 20

17 years ago
Okay, I've looked at this afresh and the simple answer why window.title is empty 
is that no one ever calls to set it from the browser code. Naturally, that means 
when it comes to drag and drop time there is no string to create the new 
shortcut file with. When it is set (such as in the mail/news window), the 
window.title works as expected.

My previous mapped window.title mapped onto document.title but that made other 
people unhappy. Therefore I think the best solution is to change change drag and 
drop to use the document's title and not the window title. This is what it 
should do anyway. The patch follows.

The title, whether from the window or document still needs to be fixed up to 
remove illegal characters & empty strings but that's another bug.

Comment 21

17 years ago
Created attachment 15213 [details] [diff] [review]
Revised drag and drop code. Comments please

Comment 22

17 years ago
This is very important! I can't believe this wasn't fixed before the 9/22
deadline! Use Composer - in mail or stand-alone. We have lots of dialogs, like
the color picker, and message dialogs that don't have titles because of this.
Raising priority -- we can't ship like this.
Keywords: rtm
Priority: P2 → P1

Comment 23

17 years ago
Renaming this bug since it deals with dragging and dropping a shortcut onto the 
desktop. Bug 41984 deals with the empty title string in the mail / news window.

In the absence of any comments I will submit both patches to the reviewers 
Summary: window.title is empty → window.title is empty for bookmark drag and drop

Comment 24

17 years ago
Bug 41984 is *this* bug. :-) Adam, what's the actual "title in mail/news" bug?

Comment 25

17 years ago
Oops :) the mail / news bug is 50682.

Comment 26

17 years ago
Is this really an "embed" bug (as noted in the keyword)?  I'm asking because I
don't want this bug to fall off the radar (since PDT is not looking at embed
keyword bugs).
patch looks fine. r||a=ben

Comment 28

17 years ago
marking nsbeta3- as we don't need this to ship pr3.  The bug is already
nominated for rtm.
Whiteboard: [nsbeta3+][PDTP2] → [nsbeta3-][PDTP2]

Comment 29

17 years ago
Emphasizing problem by modifying summary
Summary: window.title is empty for bookmark drag and drop → window.title is empty for MANY DIALOGS (e.g, most Composer messages, bookmark drag and drop)

Comment 30

17 years ago
I think there may be 2 bugs here. The patch by ben fixes the specific issue
of bookmark drag and drop, but not setting titles in "common dialogs" used
for messages.
Here is the JS we are using (from editor/base/nsEditorShell.cpp, 
  NS_WITH_SERVICE(nsICommonDialogs, dialog, kCommonDialogsCID, &rv); 
  if (NS_SUCCEEDED(rv) && dialog)
    nsCOMPtr<nsIDOMWindowInternal> cwP = do_QueryReferent(mContentWindow);
    if (!cwP) return;
    rv = dialog->Alert(cwP, aTitle.GetUnicode(), aMsg.GetUnicode());
The title being passed to the "Alert" is not displaying.

Comment 31

17 years ago
*** Bug 52901 has been marked as a duplicate of this bug. ***

Comment 32

17 years ago
*** Bug 52901 has been marked as a duplicate of this bug. ***

Comment 33

17 years ago
Renaming this bug back again. This bug deals with the internet shortcut code 
creating an empty filename because Navigator chrome never sets window.title in 
the first place.

Bug 50682 deals with the window.title value never being set on frame/dialog 
title bars.

Both bugs have approved & reviewed fixes but neither fix is going into beta 3. 
However, both bugs are nominated rtm and will be checked into the trunk as soon 
as it is permissable to do so.
Summary: window.title is empty for MANY DIALOGS (e.g, most Composer messages, bookmark drag and drop) → Internet shortcut titles are empty

Comment 34

17 years ago
Fix checked into the trunk

Comment 35

17 years ago
this needs to be marked rtm+ so it shows up on PDT radar.

Comment 36

17 years ago
Adding rtm+ 
Whiteboard: [nsbeta3-][PDTP2] → [nsbeta3-][PDTP2][rtm+]

Comment 37

17 years ago
[rtm-]. Not crash/data loss, and there's an easy workaround to rename the
desktop shortcut.
Whiteboard: [nsbeta3-][PDTP2][rtm+] → [nsbeta3-][PDTP2][rtm-]

Comment 38

17 years ago
Marking as FIXED. It's in the trunk, won't be going in the branch.
Last Resolved: 17 years ago17 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.