Closed
Bug 22735
Opened 25 years ago
Closed 25 years ago
Window title behavior in text pages w/o title
Categories
(Core :: DOM: Navigation, defect, P3)
Tracking
()
M15
People
(Reporter: benjamin, Assigned: radha)
References
()
Details
When navigating to a plain-text page (such as the above URL) from an HTML page
with a title, the old title remains displayed.
Updated•25 years ago
|
Assignee: nobody → radha
Component: Browser-General → History
Comment 1•25 years ago
|
||
Using WinNT 1999122208, the title of the page does indeed not update the
previous URL's title when going to a 'text/plain' URL (i.e., it has no concept
of <TITLE>)
I turned on the 'dump()'s in UpdateHistory of 'navigator.js' and got this:
FindShortcut: in='http://www.schak.com/counter.txt' out='null'
UpdateHistory: content's location is 'http://www.schak.com/counter.txt',
title is 'undefined'
Document http://www.schak.com/counter.txt loaded successfully
So, nsIGlobalHistory::SetPageTitle is passed an 'undefined', and the browser
title bar is not updated. (Not sure how that is reflected into C++).
Passing to default history owner 'radha' (Apologies if you're the wrong
person for this).
Assignee | ||
Updated•25 years ago
|
Assignee: radha → waterson
Assignee | ||
Comment 2•25 years ago
|
||
over to waterson..
Updated•25 years ago
|
Assignee: waterson → radha
Comment 3•25 years ago
|
||
radha: I think you are the right person to be looking at this :-). The value
that gets passed to nsIGlobalHistory::SetPageTitle() has nothing to do with the
fact that the window's titlebar is not being updated.
(FWIW, passing "undefined" to nsIGlobalHistory::SetPageTitle() is fine: global
history will remember that the page had no title.)
Assignee | ||
Updated•25 years ago
|
Status: NEW → ASSIGNED
Target Milestone: M15
Comment 4•25 years ago
|
||
add law to cc: list -- I just saw some "window title" bugs get updated that are
assigned to him. bill, is this a dup of one you've got already?
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → DUPLICATE
More or less. See bug #22174. It speaks to the same problem with respect to
viewing ftp directories. In a comment I added I noted that the same problem
exists when viewing plain text files. This one can be closed as a dup of that one.
*** This bug has been marked as a duplicate of 22174 ***
Reporter | ||
Comment 6•25 years ago
|
||
Both these bugs are likely related of bug 5707. Number 5707 deals with images
(JPEGs, in particular), has a higher priority (P2), has a later target milestone
(M17), and is assigned to nisheeth@netscape.com. It's been around since April
and is almost fully resolved. This was done by implementing the function
nsImageDocument::EndLayout(nsISupports *, nsresult, const PRUnichar *), which
generates a title-string and calls SetTitle(const nsString &) on the document
object (inherited from nsHTMLDocument). A similar EndLayout method might be used
for other types of documents.
Component: History: Session → Document Navigation
QA Contact: nobody → docshell
You need to log in
before you can comment on or make changes to this bug.
Description
•