309781 - location entry shows URL file location instead of loaded location

Status: NEW

(Core :: Networking: File, defect, P5)

Description

[Christian Persch (GNOME) (away; not receiving bug mail)]

(Not sure "Location Bar" is the right component.)

Bug 69114 added support for .lnk files on windows, and bug 308305 implemented
support for .desktop files on GNOME. Those are files that contain a link and,
when loaded, 'redirect' to the contained link.

However, when I do this, the location entry keeps showing the file:/// location
of the .desktop file, instead of the really loaded URL. (To test this, you can
create a .desktop file of this type by dragging a link from gecko to the
Nautilus desktop.)

This is linux/gtk2 trunk (2005-09-22), but bug 69114 comment 78 seems to
indicate the same happens on window with a .lnk file.

Comment 1

[Christian Persch (GNOME) (away; not receiving bug mail)]

-> docshell, as per biesi's asessment.

Comment 2

[Boris Zbarsky [:bzbarsky]]

Doesn't the location bar just show whatever URI onLocationChange gets?

How do I go about actually testing this on Linux (eg how do I create one of these .desktop files), given that I don't use GNOME?

Comment 3

[Christian :Biesinger (don't email me, ping me on IRC)]

cat > foo.desktop << EOF
[Desktop Entry]
Version=1.0
Encoding=UTF-8
Name=Verknüpfung mit Bug 309781 - location entry shows URL file location instead of loaded location
Type=Link
URL=https://bugzilla.mozilla.org/show_bug.cgi?id=309781
Icon=gnome-fs-bookmark
EOF

Comment 4

[Boris Zbarsky [:bzbarsky]]

So the issue is that docshell uses the originalURI of the channel unless LOAD_REPLACE is set.  In this case, LOAD_REPLACE is not set, so we use the originalURI, which is the file:// URI (which we set as originalURI after calling newChannel).

Setting LOAD_REPLACE in nsFileProtocolHandler::NewChannel here won't work, because NS_NewChannel will just clobber the flags right after that.

The only way I see of getting this working is to hand back a nsFileChannel from newChannel and then later Redirect() to the HTTP channel.... That would make sure all the flags are set right and play nice with the world.

Comment 5

[Christian :Biesinger (don't email me, ping me on IRC)]

I think that's the best idea and is probably how I should've implemented this originally.

Comment 6

[Firefox Bug Husbandry Bot]

Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258