Bug 149175

Summary: JS Function removed after parsing
Product: WebKit Reporter: Rodney Rehm <mail>
Component: JavaScriptCoreAssignee: Nobody <webkit-unassigned>
Status: RESOLVED WORKSFORME    
Severity: Normal CC: amichal, fpizlo, ggaren, hartman.wiki, mathias, nvasilyev, webkit-bug-importer
Priority: P2 Keywords: InRadar
Version: WebKit Nightly Build   
Hardware: Unspecified   
OS: Unspecified   
Attachments:
Description Flags
patch that has the regression test mark.lam: review+

Description Rodney Rehm 2015-09-15 11:29:20 PDT
Steps to reproduce:

Open http://rodneyrehm.de/t/css.escape (with cold cache / freshly started browser) and open DevTools and run `CSS.escape` to print the value.


Expected behavior:

The function's body is printed to the console


Actual behavior:

`undefined` is printed to the console


Additional Notes:

The issue cannot be reproduced reliably. Sometimes hitting Command+R will make CSS.escape actually hold the function, sometimes you need Command+Shift+R. Usually cleaning the cache and or restarting the browser before opening this page will make WebKit (or JavaScriptCore, or whatever) exhibit this behavior. Eventually CSS.escape will hold the function, but it may lose it again.

It feels like some script optimization routine is (sometimes) killing the function declaration, because it is not used immediately (i.e. dead code removal), or some such.


Live Testcase: http://rodneyrehm.de/t/css.escape
Related issue on Github: https://github.com/mathiasbynens/CSS.escape/issues/2
Comment 1 Mathias Bynens 2015-09-21 01:27:32 PDT
Confirmed in r189569.
Comment 2 Nikita Vasilyev 2015-11-17 19:22:52 PST

*** This bug has been marked as a duplicate of bug 126337 ***
Comment 3 Mathias Bynens 2015-12-01 09:12:34 PST
(In reply to comment #2)
> 
> *** This bug has been marked as a duplicate of bug 126337 ***

Note that this is not really a duplicate of bug 126337. Fixing bug 126337 would work around the issue in this specific case of `CSS.escape` but the underlying JavaScriptCore bug would still be there.
Comment 4 Nikita Vasilyev 2015-12-01 20:04:47 PST
Oh, you're right. Sorry about that.

It isn't about WebKit missing CSS.escape.
It is about a bizarre WebKit behavior with this particular CSS.escape shim.
Comment 5 Derk-Jan Hartman 2016-02-01 12:33:15 PST
We encountered the same issue (with the same polyfill) in Wikipedia/MediaWiki.
Issue was tracked: https://phabricator.wikimedia.org/T121991
Comment 6 Radar WebKit Bug Importer 2016-02-01 16:08:42 PST
<rdar://problem/24448680>
Comment 7 Aaron Michal 2016-03-25 12:20:10 PDT
You can also reproduce it be delaying the lookup with a setTimeout. The code below alerts('window.CSS.escape missing in event') in Version 9.1 (10601.5.17.4)

<html>
  <script src='css.escape.js'></script>
  <script type='text/javascript'>
    if (!window.CSS.escape) {
      alert('window.CSS.escape not loaded');
    }
    console.log(!!window.CSS.escape);
    setTimeout(function() {
      console.log(!!window.CSS.escape);
      if (!window.CSS.escape) {
        alert('window.CSS.escape missing in event');
      }
    },5000);
  </script>
</html>
Comment 8 Filip Pizlo 2016-05-06 10:57:34 PDT
I can't get this to reproduce in WebKit trunk right anymore.

Please reopen if you can get it to fail in trunk, nightly, etc.
Comment 9 Filip Pizlo 2016-05-06 11:07:58 PDT
Created attachment 278255 [details]
patch that has the regression test
Comment 10 Mark Lam 2016-05-06 11:09:24 PDT
Comment on attachment 278255 [details]
patch that has the regression test

rs=me if it bots don't complain.
Comment 11 Derk-Jan Hartman 2016-05-06 12:25:00 PDT
Confirmed. Still broken in Safari Version 9.1 (11601.5.17.1), but works in STP Version 9.1.1 (11601.6.17, 11602.1.29).