Closed
Bug 726779
Opened 13 years ago
Closed 7 years ago
document.location.protocol setter raising errors when protocol has a trailing ':'
Categories
(Core :: DOM: Core & HTML, defect)
Core
DOM: Core & HTML
Tracking
()
RESOLVED
FIXED
People
(Reporter: chanian, Unassigned)
References
Details
Attachments
(1 file)
172.40 KB,
image/png
|
Details |
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_6_8) AppleWebKit/535.19 (KHTML, like Gecko) Chrome/18.0.1025.11 Safari/535.19
Steps to reproduce:
Try changing the document protocol via:
document.location.protocol = 'https:';
Actual results:
The following error is raised:
Error: Component returned failure code: 0x8000ffff (NS_ERROR_UNEXPECTED) [nsIDOMLocation.protocol]
Expected results:
The page should redirect to the changed protocol [if a protocol change has occurred]
I noticed this only started happening as of Feb 10, 2012, perhaps related to the 10.1 release, but it could be unrelated.
*10.0.1 release
(In reply to Ian Chan from comment #1)
> I noticed this only started happening as of Feb 10, 2012, perhaps related to
> the 10.1 release, but it could be unrelated.
Updated•13 years ago
|
Component: Untriaged → DOM
Product: Firefox → Core
QA Contact: untriaged → general
![]() |
||
Comment 3•13 years ago
|
||
I see the same behavior in at least Firefox 9, Firefox 4, and Firefox 3.6. So this is certainly not related to 10.0.1 release.
Using "https" (note no trailing ':') works fine. The part about stripping ':' if present is new-ish in the spec. I guess we should do that. Jonas, who was working on the URI decomposition stuff?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: document.location.protocol setter raising errors → document.location.protocol setter raising errors when protocol has a trailing ':'
I don't know that anyone is working on that right now
Comment 5•13 years ago
|
||
A script like
var anchor = document.createElement("a");
anchor.href = "http://www.mozilla.org/";
anchor.protocol = "https:fooooooooooo";
alert(anchor.href);
seems to work as expected. Probably |location.protocol| should use the same URI parser/filter, rather than implement a new one.
http://hg.mozilla.org/mozilla-central/annotate/93439ef24979/content/base/src/Link.cpp#l144
Comment 6•13 years ago
|
||
However, bug 668680 seems the actual blocker rather than bug 676049.
Comment 7•9 years ago
|
||
Reproduced in FF Developer Edition 51.0a2, with `location.protocol = location.protocol`.
I sent a bug report to WHATWG HTML in order to get some statements clarified[1], confirming that the URI parser gets the blame.
[1]: https://github.com/whatwg/html/issues/2118#issuecomment-263805414
Comment 9•7 years ago
|
||
@Boris: did it get fixed? Does this bug need to remain open? If no, please resolve.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Assignee | ||
Updated•6 years ago
|
Component: DOM → DOM: Core & HTML
You need to log in
before you can comment on or make changes to this bug.
Description
•