Bug 33644 - Aliasing javascript globals to elements with matching name/id is inconsistent with Firefox and slow
Summary: Aliasing javascript globals to elements with matching name/id is inconsistent...
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: New Bugs (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-01-13 17:56 PST by James Robinson
Modified: 2017-07-18 08:30 PDT (History)
9 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description James Robinson 2010-01-13 17:56:59 PST
This code shows the text 'peekaboo' in WebKit and IE but not in Firefox:

<span id='foo' style='display:none'>peekaboo</span>
<script>
foo.style.display='';
</script>

I think we should consider matching the Firefox behavior here instead of IE.  The IE behavior is odd and likely undesirable for many web developers as well as being against the spec.  If changing this is too risky from a compatibility standpoint, we should match Firefox in standards mode and keep the old behavior only in quirks mode.

Additionally, it's fairly slow.  Since the logic for whether a global aliases an element is a bit tricky (an element is aliased if its id matches the variable name or if the name matches and it is an <img>, <form>, <applet>, <embed>,  or <object>) we can't rely on a hash lookup getElementById() to resolve the alias.  Instead, if there is a possible match (meaning any element with a matching id or name) we do a full DOM walk.  This shows up as a measurable (but small) amount of time in GMail load, on pages with a different DOM structure and variable name/element id distribution this could cause quite a significant delay.
Comment 1 Darin Adler 2010-01-14 11:38:22 PST
I believe Safari and WebKit have had this behavior for the last 7 years, so there’s been ample time for people to have made mistakes in their websites and accidentally depend on this behavior in code that’s Safari or WebKit-specific. Or code that works with IE and Safari but not Firefox (maybe there is no such thing).

How can we determine which sites will no longer work if we make this change?
How can we determine that Dashboard widgets will keep working?
How can we determine what other Mac OS X applications will keep working?
Will the iTunes Store continue to work?
Comment 2 Geoffrey Garen 2010-01-14 12:50:45 PST
(In reply to comment #0)
If we wanted to match the Firefox behavior in this case, we would need to make substantial changes to match other Firefox quirks as well. For example, Firefox treats "foo = x", "foo", and "window.foo" as referring to different variables.

All of these behaviors are odd. But what spec are you referring to? I don't think there is any spec that governs this specific quirk of the global object.
Comment 3 Sam Weinig 2010-01-14 13:13:44 PST
Are there other cases where we change scripting behavior based on Quirks/Standards mode?
Comment 4 James Robinson 2010-01-14 13:42:25 PST
(In reply to comment #2)
> (In reply to comment #0)
> If we wanted to match the Firefox behavior in this case, we would need to make
> substantial changes to match other Firefox quirks as well. For example, Firefox
> treats "foo = x", "foo", and "window.foo" as referring to different variables.
> 
> All of these behaviors are odd. But what spec are you referring to? I don't
> think there is any spec that governs this specific quirk of the global object.

I mean aliasing global variables to elements in the DOM with matching name/id, not any of the other Firefox quirks (which are internal to JS).
Comment 5 James Robinson 2010-01-14 16:10:21 PST
(In reply to comment #1)
> I believe Safari and WebKit have had this behavior for the last 7 years, so
> there’s been ample time for people to have made mistakes in their websites and
> accidentally depend on this behavior in code that’s Safari or WebKit-specific.
> Or code that works with IE and Safari but not Firefox (maybe there is no such
> thing).
> 
> How can we determine which sites will no longer work if we make this change?

Given that Firefox differs here, I do not think this will be a significant problem.  Authors that care about site compatibility will notice that their site does not work in Firefox (and hasn't in quite a while).  Authors that do not care are probably beyond our help no matter what we do.

> How can we determine that Dashboard widgets will keep working?
> How can we determine what other Mac OS X applications will keep working?
> Will the iTunes Store continue to work?

These are all very valid concerns.  The simplest way to resolve this would be to run this content in a mode different from generic web content and expose some API to the WebKit library so that programs can opt in to the more standards-compliant mode as they can.  Managing changes to the OS X provided libraries is not something I know much about.

Changing this behavior is certainly a bit risky since it has been this way in WebKit for so long, but I think it's dangerous to continue to expose this behavior to the web.  It's normally unexpected, nonstandard, and incompatible.  As time goes on it'll only get harder to change what we do here.
Comment 6 Darin Adler 2010-01-15 08:14:18 PST
(In reply to comment #5)
> Given that Firefox differs here, I do not think this will be a significant
> problem.  Authors that care about site compatibility will notice that their
> site does not work in Firefox (and hasn't in quite a while).  Authors that do
> not care are probably beyond our help no matter what we do.

Our past experience is that websites often have JavaScript code that only runs with a particular browser based on user agent checks. I’m not sure your guess is correct. We made changes like this albeit smaller scale in the past, changing from behavior that did not match Firefox to behavior that did, and subsequently struggled with websites that broke.
Comment 7 Darin Adler 2010-01-15 08:15:45 PST
(In reply to comment #4)
> (In reply to comment #2)
> > (In reply to comment #0)
> > If we wanted to match the Firefox behavior in this case, we would need to make
> > substantial changes to match other Firefox quirks as well. For example, Firefox
> > treats "foo = x", "foo", and "window.foo" as referring to different variables.
> > 
> > All of these behaviors are odd. But what spec are you referring to? I don't
> > think there is any spec that governs this specific quirk of the global object.
> 
> I mean aliasing global variables to elements in the DOM with matching name/id,
> not any of the other Firefox quirks (which are internal to JS).

I think what Geoff is referring to is the fact that if you change the global variable to element aliasing, then you'll commonly discover sites that work in IE and WebKit-based browsers due to that, and that work in Firefox due to the other Firefox quirks. If you change only the single factor, those sites no longer work.

I think we learned this during an earlier experiment with changing this behavior.
Comment 8 Ojan Vafai 2010-01-15 10:17:37 PST
It's not clear to me what the benefit of changing this is outside of purity. Have you encountered sites where this is actually causing performance problems? If we were starting from scratch, we obviously wouldn't do this, but there's a very high likelihood that a non-trivial number of sites depend on this behavior.

The downsides of this behavior are that it will confuse some people and in some cases may cause a minor performance problem. It's unlikely to cause significant performance problems in practice though. Most sites that I know of that depend on significant amounts of javascript a) don't rely heavily on globals, especially not in hot code paths and b) will wrap all their code in an anonymous function, avoiding this problem.

Not that it weighs in heavily here, but I use this "feature" all the time for quick debugging.