40063 - file:/ browsing breaks history

Status: VERIFIED FIXED

(Core :: DOM: Navigation, defect, P3)

Description

[Jeremy M. Dolan]

go to a file URL, say 'file:///foo/bar'
double click a directory to enter it, say 'images'
double click another directory to enter it, say 'testing'
double click a FILE to open it, say 'test.jpg'

Now, by the above, you should have four history entries. Well, you do.
Unfortunatly, all four entries are for:
file:///foo/bar/images/testing/test.jpg

this is related to another bug, history entries for directories aren't being
named. Also, if you don't eventually open a file, the history entry remains
blank, and 'back' will show you the current directory, unstead of the last.

Comment 1

[Jeremy M. Dolan]

The blank problem is bug 38504. I'm not sure which is blocking which, so I won't
mark anything.

Comment 2

[Jeremy M. Dolan]

win32 too. -> os:all

Comment 3

[Radha on family leave (not reading bugmail)]

cc'ing waterson. 
This bug happens  because,after a directory is viewed,  clicking in a file or 
a sub-directory replaces the current url in the page instead of going thro' 
browserAppCore's loadUrl(). Basically some call to window.content.location.url = 
<...> s'd be replaced with a call to browserAppCore.loadURL(). can you point me 
to where this is done?

Comment 4

[Chris Waterson]

The magic happens in nsDirectoryViewerFactory::CreateInstance(), here:

http://lxr.mozilla.org/mozilla/source/xpfe/components/directory/nsDirectoryViewer.cpp#1429

Comment 5

[Radha on family leave (not reading bugmail)]

Chris,
Obviously you understand directoryViewer better than I do. I thought this w'd be 
a simple fix in a JS file. The problem is what I have described above. I think 
you can fix this faster than I can.
Thanks,

Comment 6

[Chris McAfee]

yep, I'm seeing this too, linux.

Comment 7

[Chris Waterson]

-> rjc

Comment 8

[Robert John Churchill]

nsDirectoryViewerFactory::CreateInstance() just gets called to create a content 
viewer for the "http-index-format" mimetype, right?. Perhaps session history 
support probably needs to be added for the case when a content viewer is created 
in the webshell.

Radha, since you know how to add support for session history in JS, perhaps you 
can better decide where to add in similiar support via native code in the 
appropriate spot.

Comment 9

[Jeremy M. Dolan]

adding relnote, to go along with the ftp:// history bug which is relnote'd

Comment 10

[Radha on family leave (not reading bugmail)]

I don't know much about contentviewer creation etc.. and the way it is done in 
teh directory viewer. I think rick potts will understand this better.

Comment 11

[Radha on family leave (not reading bugmail)]

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

Comment 12

[Asa Dotzler [:asa]]

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

Comment 13

[Tomer Brisker]

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

Comment 14

[Tomer Brisker]

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

Comment 15

[Tomer Brisker]

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

Comment 16

[Claudius Gayle]

changing platform to ALL adding nsbeta3 keyword

Comment 17

[Claudius Gayle]

in case some triage team somewhere doubts, this bug was reproduced in a recent build - "Problem still exists in 2000080108 
linux." - 
[e-mail]

Comment 18

[Radha on family leave (not reading bugmail)]

I can't reproduce this in today's build. Entries are made for each of the 
sub-directories/files visited. However the back/forward/go menu items look 
blank. That is a different problem. But you can go back and forward properly in 
marking fixed. 

Comment 19

[Claudius Gayle]

looking at the 2000082108 builds this seems to work beautifully now...marking VERIFIED