Closed Bug 701672 Opened 8 years ago Closed 5 years ago

SVG Girl does not work in Firefox

Categories

(Web Compatibility :: Desktop, defect)

defect
Not set

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: jwatt, Unassigned)

References

()

Details

Attachments

(1 file)

This IE9 demo does not work in Firefox:

http://jsdo.it/event/svggirl

Need to investigate.
It will fail with the following message if you install HTTPS Everywhere.
> Security Error: Content at http://d37seacpprxfy8.cloudfront.net/
> may not load data from
> https://d37seacpprxfy8.cloudfront.net/svggirl/statics/02/svg.html.
Note that the problem may persist even if you disabled the add-on.
You need to
1. Disable HTTPS Everywhere,
2. Close the SVG Girl page,
3. Clear the all cache,
4. Restart Firefox, and
5. Open SVG Girl paeg again
to make it work. (Or try with Safe-mode.)
jwatt, could you reproduce it with Safe Mode or clean profile? Works for me (see comment #1).
Hmm, yeah, seems to work fine. Not sure why it wasn't working for me before.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WORKSFORME
Not work since Fiefox19+.

Timestamp: 2014/02/16 20:17:32
Error: TypeError: frame.postMessage is not a function
Source File: http://jsdo.it/event/svggirl/js/index.js?1323495035
Line: 66

Regression window(m-c)
Good:
http://hg.mozilla.org/mozilla-central/rev/5f4a6a474455
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/19.0 Firefox/19.0 ID:20121015110147
Bad:
http://hg.mozilla.org/mozilla-central/rev/8f145599e4bf
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/19.0 Firefox/19.0 ID:20121016010947
Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=5f4a6a474455&tochange=8f145599e4bf

Regression window(m-i)
Good:
http://hg.mozilla.org/integration/mozilla-inbound/rev/224fddb79a38
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/19.0 Firefox/19.0 ID:20121015103548
Bad:
http://hg.mozilla.org/integration/mozilla-inbound/rev/c350c6f28dd1
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/19.0 Firefox/19.0 ID:20121015110148
Pushlog:
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=224fddb79a38&tochange=c350c6f28dd1
Blocks: 799875
Status: RESOLVED → REOPENED
Component: SVG → DOM
Resolution: WORKSFORME → ---
Version: Trunk → 19 Branch
It might be worth spinning off a new bug for Comment 4.

This bug was originally filed and then marked WORKSFORME all before January 2012, whereas the regression in Comment 4 wasn't introduced until 9 months later. (Oct 2012)
The script is:

  var frame = window.frames['svg'] ? window.frames['svg'] : $('#svg').get(0).contentWindow;

and the markup is:

  <iframe id="svg" src="http://d37seacpprxfy8.cloudfront.net/svggirl/statics/02/svg.html"
          width="100%" frameborder="0"></iframe>

Per spec, window.frames['svg'] here should be the HTMLIframeElement, but this page expects it to be the window inside because IE and Blink are buggy and do that.  Can someone please contact Microsoft about this?
Assignee: nobody → english-us
Component: DOM → English US
Product: Core → Tech Evangelism
Version: 19 Branch → Trunk
Or fixing the spec to reflect the reality?
GSP was originally introduced only in quirks mode for compatibility with IE (bug 256932).
GSP was disabled in standards mode at the time of SVG Girl was published. We have enabled the incompatible GSP thereafter (bug 622491), so SVG Girl was broken. Most modern scripts were not affected because they were using getElementById or jQuery. This is a legacy compat issue. I think it should be considered as a bug of GSP (and the spec).
The spec was written based on our GSP implementation. It is a bit tautologic to say "GSP follows the spec".
> Or fixing the spec to reflect the reality?

Which reality?

Per spec, <iframe id="svg"> should not give the window inside a name.  That's what we and IE implement.  Blink/WebKit do give the window a name of "svg" in this situation.  So IE and we are following the spec for this part and WebKit/Blink are not.

Further per spec, window.foo looks for child windows named "foo".  If none are found, it looks for elements with id="foo" or certain element types that have name="foo".  If only one element is found, it returns the element; otherwise it returns an HTMLCollection of all the matching elements.  It's not clear to me whether anyone actually implements this part of the sec exactly as written.  We don't, for example: our GSP will look for named child windows, then do a getElementById, and if both of those fall will fall back on the "one element or a list" behavior.

In any case, for the case here, if we assume WebKit's behavior of giving the child window a name in this situation then window.svg should return that child window, and does in WebKit.  In IE window.svg also seems to return the child window in this case, even though that window has no name.  In Gecko, it returns the <iframe> itself.  We could try changing out behavior, and the spec, to match IE here, but we'd need to figure out what exactly IE is doing first.

> GSP was originally introduced only in quirks mode 

Yes, and we lost the battle to keep it that way.  Both IE and WebKit/Blink enable it in standards mode and a number of web sites depend on that behavior, so we had to follow suit.

> Most modern scripts were not affected because they were using getElementById or jQuery

Most modern pages don't use the '<iframe id="foo"> and then hope window.foo gives the window' pattern, is what you mean?

> This is a legacy compat issue.

Which "this"?  Do you have a concrete proposal for a behavior change to the GSP, based on analysis of exactly what it is IE does?

> The spec was written based on our GSP implementation. 

Not at all.  It was written based on hixie testing what various UAs did and picking some sort of middle ground.  As I said above, our current implementation doesn't follow the spec in some details (that are not relevant for this testcase), and it used to be even more different than it is now...
Flags: needinfo?(VYV03354)
Also, note that the issue here was not turning on the GSP in standards mode but the removal of the weird "only affects bareword property access" behavior.  Of course that behavior was _also_ not shared by any other UA, not implementable in ES terms, and generally insane...  Yet another way in which the spec was totally not based on our old GSP implementation.
(In reply to Boris Zbarsky [:bz] (reviews will be slow; ask someone else) from comment #10)
> Most modern pages don't use the '<iframe id="foo"> and then hope window.foo
> gives the window' pattern, is what you mean?

Yes. Otherwise much more pages would have broken.

> > This is a legacy compat issue.
> 
> Which "this"?  Do you have a concrete proposal for a behavior change to the
> GSP, based on analysis of exactly what it is IE does?

I guess IE doesn't differentiate 'id' from 'name' as many other older IE quirks.

(In reply to Boris Zbarsky [:bz] (reviews will be slow; ask someone else) from comment #11)
> Also, note that the issue here was not turning on the GSP in standards mode
> but the removal of the weird "only affects bareword property access"
> behavior.

In precise, both changes. The point is window.frame[id] was undefined before the changes.
The bareword 'svg' also points the window object on other browsers. We don't have to bring back the "only affects bareword property access" behavior.
Flags: needinfo?(VYV03354)
> I guess IE doesn't differentiate 'id' from 'name' as many other older IE quirks.

It most certainly does.

  <iframe name="foo" onload="alert(this.contentWindow.name)">

alerts "foo" but

  <iframe id="foo" onload="alert(this.contentWindow.name)">

alerts empty string in IE.

> The point is window.frame[id] was undefined before the changes

In Gecko, not in IE or WebKit...

So do you have a concrete proposal?  I'm happy to consider one; I just don't want us changing the behavior here more than once...
I can contact Microsoft, but I'm not sure what and why it needs to be contacted. 

It seems to be a demo site targeted more or less exclusively at IE. So as much as I like to go after windmill, I need a longer beard to compete with Don Quichotte. :)

So what's next? Give me food. :)
Assignee: english-us → nobody
Component: English US → Desktop
> It seems to be a demo site targeted more or less exclusively at IE.

Which pretty much goes against what Microsoft preaches for demo sites...

I'd be fine with wontfixing this too, honestly; it just bothers me to have this working in IE/Blink because they have _different_ spec-compliance bugs that both happen to make this buggy site work.
<iframe id="svg">

var frame = window.frames['svg'] ? window.frames['svg'] : $('#svg').get(0).contentWindow;
frame.postMessage(data+'', config.origin_svg);

causes 

TypeError: frame.postMessage is not a function

The reason? The demo assumes that if an ID attribute creates a window.frames reference, the reference will refer to the window object. In Firefox the ID attribute creates a reference to the IFRAME element.
Attached file 701672.htm
demo
(and site fails in Chrome/Blink too)
The id/name part was already analysed but it sounds like Blink may have changed its implementation? Did it align better with the spec or something? Because Chrome 37 fails here for exactly the same reason Firefox fails.

It's also sort of cute how the demo warns you against using IE11 and recommends IE9. Yay, Microsoft! :-p
Yes, it looks like Blink changed to align with the spec here.  Always nice when nice surprises happen.
and per bug 854890 you made them fix it ;)
Status: REOPENED → NEW
See Also: → 854890
(Not sure if this is worth working on - anyone against closing it?)
Status: NEW → RESOLVED
Closed: 8 years ago5 years ago
Resolution: --- → WONTFIX
Product: Tech Evangelism → Web Compatibility
You need to log in before you can comment on or make changes to this bug.