101149 - Previous window title sticks when accessing file:// directory listings

Status: VERIFIED FIXED

(SeaMonkey :: UI Design, defect)

Description

[Robin Green]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4+) Gecko/20010922
BuildID:    2001092206

If you're browsing some images on your local filesystem using the file://
directory listing widget, and you click on an image file and then press back,
the window title will stay as "Image __ x __ pixels".

Reproducible: Always
Steps to Reproduce:
1. Save an image to e.g. /tmp/test.jpg
2. Go to file:////tmp in the browser
3. Double-click on image
4. Click back button

Actual Results:  Window title stays as "Image __ x __ pixels".

Expected Results:  Shouldn't say it's an image because it isn't.

Comment 1

[Niels Aufbau]

I tried this several times on Windows 98, using c:\porn\ instead of /tmp.  It
worked the first time (the window title would be file:///c|/porn/).  But when I
tried it a few minutes later, that title would never appear, even when
navigating forward from a web page instead of navigating backward from an image.
 So I can confirm that this bug happens most of the time.

This bug might happen because directory listings use a low-level function to set
the title when it should be using a higher-level function.  See bug 46960 
(" - Mozilla" not appended to URL in titlebar for local index pages).

Comment 2

[Skewer]

I'm seeing this 2001092308 W98.

Comment 3

[sairuh (rarely reading bugmail)]

sounds like bug 98582, but not sure if this is the same/exact issue. is there
another existing bug for this?

Comment 4

[benc]

There is a file URL bug about Reload not firing on the most recent file URL.

Comment 5

[John Morrison]

Attachment: patch; just use document.title; remove the (unused) setup of _content.parentWindow

Comment 6

[John Morrison]

I don't know if there is a dup, but the attached patch seems to fix this.
Probably for ancient reasons, there was a scheme to set a property parentWindow 
on _content in the onload handler. Well, it turns out that the onload doesn't 
fire for directory viewer (don't know why; there is though a comment to that 
effect in directory.js). At any rate, if we just set the 'document.title' then
that title (the current URL) will be reflected back into the window's titlebar.

Look reasonable, pchen?

Comment 7

[R.K.Aa.]

*** Bug 105873 has been marked as a duplicate of this bug. ***

Comment 8

[Peter Trudelle]

->bbaetz

Comment 9

[Bradley Baetz (:bbaetz)]

Comment on attachment 51393 [details] [diff] [review]
patch; just use document.title; remove the (unused) setup of _content.parentWindow

jrgm: The default char stuff does work. Not sure why onload doesn't fire. The
stuff to load the xul listing is an evil evil evil hack.

If this works, r=bbaetz. See if rjc or waterson wants to explain whats happened
to the onload...

Comment 10

[John Morrison]

Attachment: same patch; just remove my (erroneous) comment about the onload not firing

Comment 11

[John Morrison]

Comment on attachment 59483 [details] [diff] [review]
same patch; just remove my (erroneous) comment about the onload not firing

presumptively transfer the r=bbaetz from earlier patch (only removed a comment)

Comment 12

[John Morrison]

So, bbaetz was correct; the onload is firing and 
calling checkForDirectoryListing. The real problem was that directory.js races 
the onload handler to see whether 'Init()' in directory.js gets called before 
or after _content.parentWindow has been set. This actually works sometimes on 
short directory listings, but always loses on larger directories. 

The patch just sets document.title instead, and that always results in the 
correct title being shown in the titlebar. (Not that I know why, but maybe
hyatt can explain, and sr= at the same time).

Comment 13

[Darin Fisher]

Comment on attachment 59483 [details] [diff] [review]
same patch; just remove my (erroneous) comment about the onload not firing

sr=darin (bbaetz pinged me for an sr, and this patch looks good to me)

Comment 14

[Bradley Baetz (:bbaetz)]

jrgm: Do you want me to check this in for you?

Comment 15

[John Morrison]

Yes, please. If you could check that in, that would be great.

Comment 16

[Bradley Baetz (:bbaetz)]

Checked in.

Comment 17

[sairuh (rarely reading bugmail)]

vrfy'd fixed using 2002.01.07.0x comm bits on linux rh7.2, winnt and mac 10.1.2.