Open Bug 943065 Opened 11 years ago Updated 2 years ago

Window and window both have methods

Categories

(Core :: DOM: Core & HTML, defect, P5)

defect

Tracking

()

People

(Reporter: erik, Unassigned)

References

Details

It seems that the code gen for bindings installs methods both on Window.prototype as well as on the window instance object.

assert(Window.prototype.hasOwnProperty('getComputedStyle'))
assert(false == window.hasOwnProperty('getComputedStyle'));  // FAILS
> assert(Window.prototype.hasOwnProperty('getComputedStyle'))

This is done by the codegen quickstubs.

> assert(false == window.hasOwnProperty('getComputedStyle'));

This is done by XPConnect, because we haven't finished migrating Window entirely to WebIDL bindings.

In Firefox 26 and earlier, both asserts should fail: all the methods are on the proto there.

In Firefox 27, you see the result you see.  Probably in Firefox 28 as well.

I would expect that in Firefox 29 and later both asserts will pass.

Is the transitional situation a known web compat problem somehow?
Flags: needinfo?(erik)
Hmm, I don't think comment 1 is completely correct. I think it's more like:

FF27 and earlier
Window.prototype.hasOwnProperty('getComputedStyle') is true
Object.getPrototypeOf(window).hasOwnProperty('getComputedStyle') is true
window.hasOwnProperty('getComputedStyle') is false

FF28
Window.prototype.hasOwnProperty('getComputedStyle') is true
Object.getPrototypeOf(window).hasOwnProperty('getComputedStyle') is true
window.hasOwnProperty('getComputedStyle') is true

Some future release
Window.prototype.hasOwnProperty('getComputedStyle') is false
Object.getPrototypeOf(window).hasOwnProperty('getComputedStyle') is false
window.hasOwnProperty('getComputedStyle') is true

But yes, if the transitional phase is a problem we'd like to know.
This did break Polymer. I would not worry about breaking us at this point. We are living on the edge and we are pre-alpha.

For now we have a work around so the transition will be smooth.
Flags: needinfo?(erik)
Could you explain what happened? Is the problem that the property lives on both, or that window now has the property as an own property? I'm asking because the latter is what we'll end up with, and we need to know whether that's web-compatible, otherwise we need to get WebIDL changed.
Flags: needinfo?(erik)
The problem is that window now has the method as an own property which shadows the prototype method (if present). Our work around is to delete the instance method so that the expected prototype method gets called.

http://heycam.github.io/webidl/#Global

"Interface members from the interface (or consequential interfaces) will correspond to properties on the object itself rather than on interface prototype objects."

Yeah, this is clearly not compatible with any of the existing browsers and it is inconsistent with how the rest of WebIDL works. I'm sure there is a reason for why it is speced this way but I cant think of why?
Flags: needinfo?(erik)
Hmm.  So your workaround will break once we finish the WebIDL migration for Window, right?

> I'm sure there is a reason for why it is speced this way but I cant think of why?

Because people dealing with the prefixing mess like to write, in global scope:

  var requestAnimationFrame = 
    window.requestAnimationFrame || 
    window.mozRequestAnimationFrame || 
    window.webkitRequestAnimationFrame ||
    window.msRequestAnimationFrame;

for example.

This works in a browser that supports one of the prefixed methods, but does NOT work, for obvious reasons, in a browser that only supports the unprefixed method but puts it on Window.prototype.

There was a lengthy discussion about exactly this issue on public-script-coord a while back, and the decision that was reached was that the only thing to do is to put all properties and methods of Window on the window object itself.

The only other remotely web-compatible option is to require that all browsers forevermore (including ones that are not based Blink or WebKit or Gecko or Trident) support one of the prefixed names for these methods that people are currently using.  And that people never drop prefixed APIs on Window, ever.
Right I forgot that web devs do stupid things :'(

Don't worry about our work around. (Currently we extract the builtin using a simple [[Get]] on the instance so we get the method no matter what. The issue was that we only installed our wrapped version on the prototype.)
Blocks: 932322
https://bugzilla.mozilla.org/show_bug.cgi?id=1472046

Move all DOM bugs that haven’t been updated in more than 3 years and has no one currently assigned to P5.

If you have questions, please contact :mdaly.
Priority: -- → P5
Component: DOM → DOM: Core & HTML
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.