requestAnimationFrame triggers edge specific bug when returning an object without a prototype
Fixed Issue #8187485
Details
- Author
- Ralf N.
- Created
- Jul 15, 2016
- Privacy
- This issue is public.
- Found in
- Standard affected
- Timing control for script-based animations
- Found in build #
- 25.10586
- Reports
- Reported by 1 person
Sign in to watch or report this issue.
Steps to reproduce
- Try this:
requestAnimationFrame( function(ts){ return {} } );
// no error
- Then try this:
requestAnimationFrame( function(ts){ return Object.create( null ) } ); // error when animation frame renders
Which will give the very “usefull” output of:
SCRIPT5001: Number expected
It only happens in Edge.
Every spec, including MDN documentation says you shouldn’t do anything with the return value of a callback in requestAnimation in the first place. But its scary to think that are subsystems that are unable to deal with Object.create( null ).
PS. As a general rule, please consider any error without a proper line-number a serious offense. Supporting Edge is not a requirement for us right now, but we felt like being inclusive – but getting an error without a functioning line-number, that you can’t find using step-debugging, is an impossible to support situation in general. If you want developers to embrace Edge, please search for all places in your code base where these kind of error messages are outputted, and mark a big fat ‘TODO’ above it, to at least internally acknowledge that situation is far from optimal and some developer is taking the (way too easy) way out.
Comments and activity
-
Also we can’t copy and paste the build number from the ‘About’ section.
-
Microsoft Edge Team Changed Assigned To to “Brad E.”
Changed Assigned To to “Rick J.”
Changed Assigned To to “Rico M.”
Changed Assigned To from “Rico M.” to “Josh P.”
Changed Status to “Confirmed”
Changed Assigned To from “Josh P.” to “Jeff W.”
-
Hey Ralf, thanks for this bug report. You’re right that for requestAnimationFrame, there’s nothing to do on the callback function’s return value. Our implementation shares code with other features (like addEventListener) which does sometimes try to interpret a returned value in a few cases. In this shared code’s case, it always pokes the return value a little bit. I’ll update this shared code to be smarter about leaving the return value alone when our internal callers truly don’t care about the return value.
I also completely agree about script errors that are short on debugging information (i.e. line and column 0, etc). In this case, the JavaScript error that was generated was not due to an operation in your JavaScript code, but rather due to an operation from internal platform code. There aren’t many good options for reporting here…I think the best might be to just hide the error from user code (since it’s not quite user code’s fault the error is being thrown). If you open a new bug and post the bug # here, I’ll grab it and see about making some progress on it too.
-
Nevermind! I opened 10957024 on your behalf, and you can view/track it here:
https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/10957024/
- Microsoft Edge Team
Changed Status from “Confirmed” to “In progress”
Changed Status from “In progress” to “In code review”
Changed Status from “In code review” to “Fixed”
-
This will be fixed in an upcoming insider flight, but after the Creator’s Update is released later this spring. Thanks again for the report!
You need to sign in to your Microsoft account to add a comment.
Sign in