Bug 155749 – REGRESSION(r196648): [GTK] The Spotify web player does not work since r196648

• Component: WebKitGTK
• Status: RESOLVED FIXED

[Alberto Garcia]

You can reproduce this by logging in to https://play.spotify.com

You'll need a Spotify account and the Flash plugin.

2.10.9 works fine, 2.12.0 does not (you can only see the side bar, but not anything else). I haven't tried any of the 2.11.x releases, though.

[Carlos Garcia Campos]

d5618d20fdccdc627970c893f3d72f64447490ee is the first bad commit
commit d5618d20fdccdc627970c893f3d72f64447490ee
Author: [e-mail] <[e-mail]@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Date:   Tue Feb 16 20:23:02 2016 +0000

    [Web IDL] Operations should be on the instance for global objects or if [Unforgeable]
    https://bugs.webkit.org/show_bug.cgi?id=154120
    <rdar://problem/24613231>
    
    Reviewed by Gavin Barraclough.
    
    LayoutTests/imported/w3c:
    
    Rebaseline now that more checks are passing.
    
    * web-platform-tests/html/dom/interfaces-expected.txt:
    
    Source/JavaScriptCore:
    
    Have putEntry() take a thisValue parameter in addition to the base,
    instead of relying on PropertySlot::thisValue() because this did not
    always do the right thing. In particular, when JSDOMWindow::put() was
    called to set a function, it would end up setting the new value on the
    JSDOMWindowShell instead of the actual JSDOMWindow.
    JSDOMWindow::getOwnPropertySlot() would then not be able to find it.
    Therefore the following would fail:
    $ window.open = "test"
    $ console.log(window.open) // prints the native function instead of "test"
    
    * runtime/JSObject.cpp:
    (JSC::JSObject::putInlineSlow):
    * runtime/Lookup.h:
    (JSC::putEntry):
    (JSC::lookupPut):
    
    Source/WebCore:
    
    Operations should be on the instance for global objects or if
    [Unforgeable] as per the Web IDL specification:
    - http://heycam.github.io/webidl/#es-operations
    - http://heycam.github.io/webidl/#dfn-unforgeable-on-an-interface
    
    This patch implements this behavior in order to align
    with the specification and other browsers.
    
    No new tests, already covered by existing tests.
    
    * bindings/js/JSDOMWindowCustom.cpp:
    (WebCore::jsDOMWindowGetOwnPropertySlotRestrictedAccess):
    Update function names now that they have "Instance" in their
    name instead of "Prototype".
    
    (WebCore::JSDOMWindow::getOwnPropertySlot):
    - Update function names now that they have "Instance" in their
      name instead of "Prototype".
    - Move the functions hard-coding *before* the static table check
      now that these functions are in the static table to maintain
      the previous behavior.
    
    * bindings/js/JSLocationCustom.cpp:
    (WebCore::JSLocation::getOwnPropertySlotDelegate):
    Update function names now that they have "Instance" in their
    name instead of "Prototype".
    
    * bindings/scripts/CodeGeneratorJS.pm:
    - Move functions to the instance if their interface is a global
      object or if they are marked as [Unforgeable]. Operations are
      now treated more like attributes, as they can now be either on
      the instance or the prototype. In a lot of places, I now use
      the naming "properties" instead of "attributes" as "properties"
      refer both "attributes" and "operations" / "functions".
    
    * bindings/scripts/test/JS/JSTestInterface.cpp:
    * bindings/scripts/test/JS/JSTestObj.cpp:
    Rebaseline bindings tests.
    
    LayoutTests:
    
    * inspector/model/remote-object-get-properties-expected.txt:
    Rebaseline test because the order of static properties has changed:
    functions are now before constants instead of after.
    
    git-svn-id: http://svn.webkit.org/repository/webkit/trunk@196648 268f45cc-cd09-0410-ab3c-d52691b4dbfc

[Carlos Garcia Campos]

Chris, any idea about this or how I can debug it?

[Carlos Garcia Campos]

This is now working in trunk, I'll try to find the commit that fixed it.

[Carlos Garcia Campos]

It seems it was r199087, that I've just merged in the stable branch in r199489, so it will be fixed in 2.12.1