Bug 142792

Summary: Objects with numeric properties intermittently get a phantom 'length' property
Product: WebKit Reporter: osolo
Component: JavaScriptCoreAssignee: Michael Saboff <msaboff>
Status: RESOLVED FIXED    
Severity: Normal CC: caitp, fpizlo, ggaren, jstephenson-wkbgz, mathias, m.goleb+bugzilla, mhahnenb, msaboff, osolo, ossy, webkit-bug-importer, ysuzuki
Priority: P2 Keywords: InRadar
Version: 528+ (Nightly build)   
Hardware: iPhone / iPad   
OS: iOS 8.1   
Bug Depends on:    
Bug Blocks: 108645    
Attachments:
Description Flags
Converted supplied test into a regression test
none
Patch ossy: review+

osolo
Reported 2015-03-17 14:53:56 PDT
There is a timing bug in iOS8 that causes mobile Safari to incorrectly report a 'length' on objects that don't have one. To the best of my knowledge, this happens on iOS8+, possibly only on 64-bit systems. The bug is triggered for objects that have only numeric properties. For example: foo = { 1: 'a', 2: 'b', 3: 'c' } In this case, if you query foo.length then mobile Safari will sometimes return 4 (the highest property + 1). This causes strange failures in functions like jQuery's $.each() or Underscore's _.each() since the appearance of the '.length' property makes them believe the object is an array. When the bug manifests itself, the following be true: a = foo.length; b = typeof a; c = foo.hasOwnProperty('length') --> a == 4 // should have been undefined b == 'number' // should have been 'undefined' c == false // correct Both jQuery and Underscore to use the 'typeof' test on the length property, and I have advised them to add an 'hasOwnProperty' check as well. You can see more background and some repro steps at the following Stack Overflow discussion: http://stackoverflow.com/questions/28155841/misterious-failure-of-jquery-each-and-underscore-each-on-ios The Underscore team have apparently managed to create an automated test for this: https://github.com/jashkenas/underscore/issues/2081 The jQuery issue is here: https://github.com/jquery/jquery/issues/2145
Attachments
Converted supplied test into a regression test (2.53 KB, patch)
2015-03-26 16:16 PDT, Michael Saboff
no flags
Patch (5.15 KB, patch)
2015-03-27 07:06 PDT, Michael Saboff
ossy: review+
Radar WebKit Bug Importer
Comment 1 2015-03-26 04:12:05 PDT
Yusuke Suzuki
Comment 2 2015-03-26 08:04:12 PDT
ossy, now I think it may be related to aarch64 failures with "length" property.
Michael Saboff
Comment 3 2015-03-26 15:49:40 PDT
I can reproduce on iOS ARM64 in ToT (r182023) WebKit. It doesn't happen in on ARM32 or Mac. Curious.
Michael Saboff
Comment 4 2015-03-26 16:16:48 PDT
Created attachment 249534 [details] Converted supplied test into a regression test
Michael Saboff
Comment 5 2015-03-26 17:18:06 PDT
Looks like we have a bad instruction optimization when comparing a literal with a single bit to a register in MacroAssemblerARM64::branchTest32(). Patch in progress.
Michael Saboff
Comment 6 2015-03-27 07:06:00 PDT
Csaba Osztrogonác
Comment 7 2015-03-27 07:18:05 PDT
Comment on attachment 249564 [details] Patch nice catch, r=me
Michael Saboff
Comment 8 2015-03-27 07:29:15 PDT
Mark Hahnenberg
Comment 9 2015-03-27 10:26:54 PDT
This might be my favorite bug/fix ever.
Csaba Osztrogonác
Comment 10 2015-03-27 11:03:12 PDT
*** Bug 142575 has been marked as a duplicate of this bug. ***
Michał Gołębiowski-Owczarek
Comment 11 2015-03-27 16:25:54 PDT
It would be great to have it backported to iOS 8. If that's not planned (or if it's planned but we're be notified about that) we'll have to publish another patch release of jQuery dedicated to Safari; the first one was: http://blog.jquery.com/2014/12/18/jquery-1-11-2-and-2-1-3-released-safari-fail-safe-edition/
Note You need to log in before you can comment on or make changes to this bug.