NECKO: nsHttpUrlImpl::ParseURL() doesn't handle "javascript:" protocol

VERIFIED DUPLICATE of bug 1646

Status

()

P2
normal
VERIFIED DUPLICATE of bug 1646
20 years ago
19 years ago

People

(Reporter: beard, Assigned: brendan)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: waiting on javascript: to work.)

(Reporter)

Description

20 years ago
Plugins can use "javascript:" URLs to obtain information from DOM etc. They
don't parse properly (an error is returned).

Updated

20 years ago
Status: NEW → ASSIGNED

Comment 1

20 years ago
*** Bug 3398 has been marked as a duplicate of this bug. ***

Updated

20 years ago
Target Milestone: M6

Comment 2

20 years ago
Per DP's suggestion marking these till M8. Though Necko lands with M7, we will
be able to verify it for M8.

Comment 3

19 years ago
I'm moving this to target M9, Necko will be enabled somewhere during late M8 or
early M9.  We will need to get on this and it cannot be postponed past the M9
milestone.

Comment 4

19 years ago
Changing all Networking Library/Browser bugs to Networking-Core component for
Browser.

Occasionally, Bugzilla will burp and cause Verified bugs to reopen when I do
this in a bulk change.  If this happens, I will fix. ;-)

Updated

19 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → FIXED
Summary: nsHttpUrlImpl::ParseURL() doesn't handle "javascript:" protocol → NECKO: nsHttpUrlImpl::ParseURL() doesn't handle "javascript:" protocol

Comment 5

19 years ago
Fixed now with Necko. Pl. verify.

Updated

19 years ago
Whiteboard: will attempt to verify when release builds available

Updated

19 years ago
Whiteboard: will attempt to verify when release builds available → asked reporter to verify

Comment 6

19 years ago
beard, can you verify if this is, in fact, fixed with necko
(Reporter)

Updated

19 years ago
Status: RESOLVED → REOPENED
(Reporter)

Comment 7

19 years ago
I can't easily verify this, I tried a couple of javascript URLs, such as:

javascript:1+1
javascript:window.open('http://www.apple.com')

Neither of these produce any sensible result with viewer or apprunner. Of
course, this could be a problem downstream from URL parsing. Still, the first
example is getting converted into the URL:

http://javascript:1/

which of course fails to load. So, I still think there are some problems.

Updated

19 years ago
Resolution: FIXED → ---

Comment 8

19 years ago
Clearing Fixed resolution due to reopen.

Updated

19 years ago
Target Milestone: M9 → M10

Comment 9

19 years ago
Marking till javascript: comes up (brendan?)

Updated

19 years ago
Whiteboard: asked reporter to verify → waiting on javascript: to work.
(Assignee)

Updated

19 years ago
Depends on: 1646

Updated

19 years ago
Assignee: gagan → brendan
Status: REOPENED → NEW
(Assignee)

Updated

19 years ago
Status: NEW → RESOLVED
Last Resolved: 19 years ago19 years ago
Resolution: --- → DUPLICATE

Comment 10

19 years ago
This sounds like a dup of 1646, unless you're telling me that control flows
through HTTP when the use types in a javascript: URL -- that would be a necko
regression, cuz M9 suppored javascript: URLs typed into the Location toolbar.

/be

*** This bug has been marked as a duplicate of 1646 ***

Comment 11

19 years ago
checked for duplication with bug# 1646

Comment 12

19 years ago
Bulk move of all Networking-Core (to be deleted component) bugs to new
Networking component.

Updated

19 years ago
Status: RESOLVED → VERIFIED

Comment 13

19 years ago
Verified duplicate of bug 1646.  Bug 1646 covers the same ground.
You need to log in before you can comment on or make changes to this bug.