nsNetlibService::CreateURL bug

VERIFIED FIXED in M9

Status

()

Core
HTML: Parser
P2
major
VERIFIED FIXED
19 years ago
19 years ago

People

(Reporter: Michael Lowe, Assigned: Warren Harris)

Tracking

Trunk
x86
Windows NT
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [TESTCASE] CreateURL must be fixed to correctly interpret ":" character, URL)

Attachments

(1 attachment)

(Reporter)

Description

19 years ago
Page does not load on 1999062808 build: a parser or network bug?

Updated

19 years ago
Assignee: rickg → pollmann

Comment 1

19 years ago
Eric -- the parser seems to be doing the right thing with this document, but
that frames don't load. If your replace the given URL's with a simple file URL
it works, so I suspect a frame bug or a URL resolution bug.

Updated

19 years ago
Whiteboard: [MAKINGTEST] Antti.Nayha@oulu.fi
(Reporter)

Updated

19 years ago
Severity: normal → major
Priority: P3 → P2

Updated

19 years ago
Assignee: pollmann → warren

Comment 2

19 years ago
The bug lies in nsNetlibService::CreateURL.
The following parameters are passed in:

aSpec = "/RUN?FN=bottom_frame&locale=en&Cook=&SEQ=&dyn=NoRef:5712&ver=3.0.0"
aContextURL = "http://www.bigfoot.com"

aSpec is a relative URL, but CreateURL finds the : at position 51 in aSpec and
assumes it found a protocol specifier, then treats aSpec as an absolute URL.

The generated url is then:
http://

When it should be:
http://www.bigfoot.com/RUN?FN=bottom_frame&locale=en&Cook=&SEQ=&dyn=NoRef:5712&ver=3.0.0

Assigning to warren as cvsblame points that way.

Updated

19 years ago
Summary: Page does not load → nsNetlibService::CreateURL bug
(Reporter)

Updated

19 years ago
Target Milestone: M9
(Assignee)

Updated

19 years ago
Status: NEW → ASSIGNED
(Assignee)

Comment 3

19 years ago
Interesting. We'll have this problem in necko too. I'll fix it.

Comment 4

19 years ago
This may be partially to blame for javascript: URL's not working too.

<HTML>
 <BODY>
  <A HREF="javascript:alert('foo')">Alert foo.</A>
 </BODY>
</HTML>

When I click on the anchor, the URL bar changes to http://

Also noticed this on bug 4559
http://cgi1.adobe.com/newsfeatures/puzzles/imagehunt/shiftyhues/puzzle.cgi#top
Click on "Show Hint".

Comment 5

19 years ago
Okay, sorry, nevermind.  javascript: URL's currently just generate a
nsHttpURLFactory, the two problems are not related.  Similar symptoms != similar
problem.  :)

Updated

19 years ago
Whiteboard: [MAKINGTEST] Antti.Nayha@oulu.fi → [TESTCASE] CreateURL must be fixed to correctly interpret ":" character

Comment 6

19 years ago
Attaching a minimized test case & rewriting the bug report in accordance to the
guidelines.


Overview description:
  Mozilla shortens certain types of URLs in a frameset document to "http://"
  (See pollmann@netscape.com's earlier message for detailed information.)

Steps to reproduce:
  1) View the attached test case.

Actual results:
  The two frames on the page are blank (on Win32, the desktop background "shines
  through").

Expected results:
  The two frames should both show a document (a simple list of ad banners)
  from http://www.bigfoot.com/

Build date & platform:
  - originally reported on build 1999062808 (platform unknown)

Additional builds & platforms:
  - Apprunner 1999072711 (Windows NT 4.0 SP4)
  - Viewer 1999072711 (Windows NT 4.0 SP4)
  - M8 Apprunner (Windows NT 4.0 SP4)

Comment 7

19 years ago
Created attachment 1031 [details]
Minimized test case
(Assignee)

Updated

19 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → FIXED
(Assignee)

Comment 8

19 years ago
I think this is fixed with Gagan's URL changes.

Updated

19 years ago
Status: RESOLVED → VERIFIED

Comment 9

19 years ago
Verified fixed on 08/15/1999 Win32 Apprunner.
You need to log in before you can comment on or make changes to this bug.