Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 400454

Summary:	Test failure in Firefox
Product:	[ECD] Orion	Reporter:	Mark Macdonald <mamacdon>
Component:	Client	Assignee:	Simon Kaegi <simon_kaegi>
Status:	RESOLVED FIXED	QA Contact:
Severity:	normal
Priority:	P3	CC:	libingw, simon_kaegi
Version:	2.0	Flags:	mamacdon: review+
Target Milestone:	2.0 RC2
Hardware:	PC
OS:	Windows 7
Whiteboard:

Description Mark Macdonald

2013-02-11 10:02:17 EST

http://download.eclipse.org/orion/drops/I201302102230/Firefox-17.0-testResults.html

There is a test failure in urlUtils, Firefox only.
> testWithBadURLAndPair2
> Failure
> AssertionError: deepEqual failed - expected: [null], actual: [[{"segmentStr":"There is URL "},{"segmentStr":"abcde","urlStr":"abcde"},{"segmentStr":" and it is valid"}]].

Comment 1 Mark Macdonald

2013-02-11 10:08:14 EST

It is caused by line 30 in urlUtils.js:
> new URL(match[2]).href

I'm not sure what the intended behavior of this is (haven't read the spec), but it behaves inconsistently in Firefox vs. Chrome:

> new URL("abcde").href   // "abcde" in Firefox
> new URL("abcde").href   // "" in Chrome

Comment 2 Mark Macdonald

2013-02-11 10:37:56 EST

Minimal test code:

> var a = document.implementation.createHTMLDocument("").createElement("a");
> a.href = "abcde";
> a.href;    // "" in Chrome, "abcde" in Firefox

The href here is supposed to be a relative URI. Chrome ignores it completely: setting the href has no effect if the URI lacks a scheme. So I think Firefox is correct and Chrome is bugged.

Note that the difference only happens with DOMImplementation, not Document. If you run this code instead:

> var a = document..createElement("a");
> a.href = "abcde";
> a.href;    // "abcde"

You get the same result in both browsers.

Comment 3 Simon Kaegi

2013-02-11 10:55:39 EST

I think Chrome's behavior is correct here as the document has no browsing context and so that href is not relative to anything and invalid until a "base" is set.

Not that it matters... as we still have to fix this.

Comment 4 Mark Macdonald

2013-02-14 13:03:40 EST

reviewed

Comment 5 Simon Kaegi

2013-02-14 13:06:57 EST

Fixed.