Closed
Bug 9009
Opened 25 years ago
Closed 25 years ago
nsNetlibService::CreateURL bug
Categories
(Core :: DOM: HTML Parser, defect, P2)
Tracking
()
VERIFIED
FIXED
M9
People
(Reporter: michael.j.lowe, Assigned: warrensomebody)
References
()
Details
(Whiteboard: [TESTCASE] CreateURL must be fixed to correctly interpret ":" character)
Attachments
(1 file)
|
387 bytes,
text/html
|
Details |
Page does not load on 1999062808 build: a parser or network bug?
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•25 years ago
|
Whiteboard: [MAKINGTEST] Antti.Nayha@oulu.fi
|
Reporter | |
Updated•25 years ago
|
Severity: normal → major
Priority: P3 → P2
|
||
Updated•25 years ago
|
Assignee: pollmann → warren
|
|
||
Comment 2•25 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•25 years ago
|
Summary: Page does not load → nsNetlibService::CreateURL bug
|
|
Reporter | |
Updated•25 years ago
|
Target Milestone: M9
|
Assignee | |
Updated•25 years ago
|
Status: NEW → ASSIGNED
|
|
Assignee | |
Comment 3•25 years ago
|
||
Interesting. We'll have this problem in necko too. I'll fix it.
|
|
||
Comment 4•25 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•25 years ago
|
||
Okay, sorry, nevermind. javascript: URL's currently just generate a
nsHttpURLFactory, the two problems are not related. Similar symptoms != similar
problem. :)
|
|
||
Updated•25 years ago
|
Whiteboard: [MAKINGTEST] Antti.Nayha@oulu.fi → [TESTCASE] CreateURL must be fixed to correctly interpret ":" character
|
|
||
Comment 6•25 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•25 years ago
|
||
|
|
Assignee | |
Updated•25 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
|
|
Assignee | |
Comment 8•25 years ago
|
||
I think this is fixed with Gagan's URL changes.
|
|
||
Updated•25 years ago
|
Status: RESOLVED → VERIFIED
|
|
||
Comment 9•25 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.
Description
•