cleanup - stop converting \ to / for win32 url parsing




18 years ago
16 years ago


(Reporter: Nathan Adams, Assigned: Andreas Otte)


Windows 2000

Firefox Tracking Flags

(Not tracked)


(Whiteboard: fix in hand, URL)


(2 attachments)



18 years ago
*Reproducing the bug
1. click on a thumbnail on the left side frame (such as "Entry Point")

*Results (what happens)
1. right frame will begin loading text
2. mozilla will stop when it tries to load the image
3. error message: " could not be found. Please check the name
and try again."

*Expected (what should have happened)
1. click the thumbnail
2. right frame loads text
3. right frame loads large image

*HTML used to query the images (one small snippet of it anyhow)
<a href="" TARGET="main"><img SRC="devoured_thumb.jpg"
ALT="Devoured" HSPACE=2 VSPACE=2 BORDER=0 height=65 width=65></a><a
href="" TARGET="main"><img SRC="entrypoint_thumb.jpg"
ALT="Entry Point" HSPACE=2 VSPACE=2 BORDER=0 height=65 width=65></a>

*HTML for the resulting "large image" page (note this is the complete html)
<meta name="Author" content="Neil Blevins, Soulburn Studios,">
<meta name="KeyWords" content="Neil, Blevins, Soulburn, Studio, Art, Computer,
CG, Animations, MAX, 3DS, 3DStudio, Plugins, Robots, Mechs, Creatures, Monsters,
SciFi, Fantasy, Images, Paintings, Sketches, Logos, Models">
<title>Soulburn Studios Art Gallery</title>
<body text="#CCCCCC" bgcolor="#000000" link="#999891" vlink="#676763"
<td BGCOLOR="#333333">
<b><dt><center><font color="#FFFFFF">Entry Point</font></dt></center></b>
<dt><center>No. 3D87, Feb 23rd 2000</dt></center>
<dt><center>Programs: MAX 3.1, Grass-o-matic, Rayfx area Lights,
<img SRC="..\artgallery\entrypoint.jpg">
<td BGCOLOR="#333333">&nbsp;</td>
Another mood piece, the hairs were created using grass-o-matic, the nice soft
shadows using Blur's new Area Lights. Textures in Photoshop, and post process
blurring effects using max's built in render effects. It can be anything from an
alien landscape to an extreme closeup of some one's green skin, you be the judge.
<td BGCOLOR="#333333">&nbsp;</td>

Comment 1

18 years ago
the error message is gone on linux 2000-050308 but the image doesn't load.
Doesn't load if frame is opened in new window either.
So a real testcase can be abstracted from for instance this URL:

This gotta be a dup of something but i haven't found it yet.
I can't see this on 20000512 Win 95. - are you 
still seeing this?


Comment 3

18 years ago
Image loads for me with tonight's build, NT.  I'm waiting for my Linux build to 
complete, but will test that before closing this as worksforme.
pollmann - what happened when you tested this with your Linux build? 


Comment 5

18 years ago
Tested with Build # 2000051808 on RH 6.2. Bug was reproduced everytime.

Comment 6

18 years ago
I am also able to reproduce this bug, taking a look.
Ever confirmed: true


18 years ago
Target Milestone: --- → M18

Comment 7

18 years ago
This might have something to do with the fact that time image's URL is:

<IMG SRC="..\artgallery\devoured.jpg">

Note the use of backslashes instead of forward slashes.

Comment 8

18 years ago
Apparently URL parsing is horked on Linux:

<IMG SRC="..\artgallery\devoured.jpg">

This URL gets translated into a request for / on the host

As you might guess, DNS lookup for that hostname fails, so the resulting error 
message is displayed.

Comment 9

18 years ago
I have a fix for this in my tree.
Whiteboard: fix in hand

Comment 10

18 years ago
CC'ing people who might be able to review the very tiny patch I'm about to post.

Comment 11

18 years ago
Created attachment 8885 [details] [diff] [review]
URL Parsing fix for \ on non-win32 platforms (malformed testcase)


18 years ago
Target Milestone: M18 → M17

Comment 12

18 years ago
Simplified testcase available internally at

Comment 13

18 years ago
andreas should review this. It's small, but url parsing ripple effects can be 

Comment 14

18 years ago
I don't like it at all. \ is a valid normal character inside URLs. It can always
happen with charset conversion to get this. The character to show the URL
hierarchy is /. I have strong requests to even remove the \ handling in
CoalesceDirs completly not to enhance it. Putting this change in will reopen
other bugs. I don't know how it was done with 4.x.

I would mark this WONTFIX. Let the Homepage be changed.

Comment 15

18 years ago
Thanks Andreas, I will mark this one WONTFIX then.  However, let me put in one 
more strong vote in to make \ work either on all platforms or none of them, this 
should definitely NOT be a platform specific thing - why would we display this 
page (in)correctly only for people running their browser on Windows?
Last Resolved: 18 years ago
Resolution: --- → WONTFIX

Comment 16

18 years ago
I'm currently running my build with a removed conversion of \ to / for XP_PC. 

Judson, as new owner of the DocShell: 

What about doing some fallback error handling when loading images or following
relative links or even loading absolute URLs? If we fail for any reason in
loading an image (or something similar) and the path contains a \, we could
convert it to / and try again. This would keep urlparsing clean of the
conversion stuff and we can do it only if something fails. This would allow
loading of urls including \ which are perfectly valid on linux and also (after a
load failure we could hide!) urls of the type described in this bug.

Comment 17

18 years ago
Marking verified wont fix.

Comment 18

18 years ago
> I'm currently running my build with a removed conversion of \ to / for XP_PC.

This apparently never got checked in because the test case still displays the
image on Windows.  Are there any plans to check it in?

Comment 19

17 years ago
There is a meta bug (bug 36736) on this uri fixup bugs. I still  think it is
better to solve the whole problem instead of fixing a symptom. 
Blocks: 63736

Comment 20

17 years ago
So that this bug won't be crossed off the list of depends for Bug 63736 (the
meta bug), I'm reopening it.

I agree that we should fix the problem and not the symptom.  :)  I think this
means that 1) do the fixups at the docshell level if loading fails, per your
comment above and then 2) make our URL parsing platform neutral (check in your
fix to remove conversion of \ to / from XP_PC)?

That actually means that this bug depends on 63736 and not vice versa, because
we can't fix this one until the docshell handles failed loads or there will be
problems...  ;)
Resolution: WONTFIX → ---


17 years ago
No longer blocks: 63736
OS: Linux → Windows 2000
Summary: mozilla unable to find domain for frame → cleanup - stop converting \ to / for win32 url parsing
Target Milestone: M17 → Future


17 years ago
Depends on: 63736

Comment 21

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

Comment 22

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

Comment 23

17 years ago
QA Contact update
QA Contact: petersen → amar

Comment 24

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

Comment 25

17 years ago
Created attachment 44061 [details] [diff] [review]
patch: partial fix - stop converting \ to / for win32 url parsing

Comment 26

17 years ago
Reassigning to you Andreas - this seems like more your area.  Just attached a
partial patch that probably breaks something or other on WIN32 (haven't tested).
 Maybe it doesn't help much - maybe it will save a few keystrokes.  :)
Assignee: pollmann → andreas.otte

Comment 27

17 years ago
If we go for this, it is exactly the patch we have to use. I have brought the
topic to netscape.public.mozilla.netlib to get more opinions on it.

Comment 28

17 years ago
Marking as dup of bug 32895, the patch attached there is more complete.

*** This bug has been marked as a duplicate of 32895 ***
Last Resolved: 18 years ago17 years ago
Resolution: --- → DUPLICATE

Comment 29

16 years ago
VERIFIED/dupe of networking bug
Component: HTMLFrames → Networking
QA Contact: amar → benc
You need to log in before you can comment on or make changes to this bug.