1481124 - Menu takes longer to open in Firefox than in chrome

Status: NEW

(Core :: JavaScript Engine, defect, P3)

Description

[Karl Dubost💡 :karlcow]

This is a spin-off of https://webcompat.com/issues/18031
This is related to a performance issue. Flagging with [qf]

Steps to reproduce

Comment 1

[Karl Dubost💡 :karlcow]

Entered too fast. :)

Steps to reproduce 

1. With Firefox Android (or Firefox Desktop RDM + Firefox Android UA + touch events)
2. Go to https://www.samsung.com/us/
3. tap the 3-bars menu
4. tap mobile
5. (wait) the menu takes a long time to open

(On the other hand on chrome this is alsmost instantaneous)


Performance Profile. (on desktop with RDM mode)
https://perfht.ml/2Mm49LL

Comment 2

[Olli Pettay [:smaug][[e-mail]]]

Something weird with BytecodeParser::parse

Comment 3

[André Bargull [:anba]]

BytecodeParser::parse() is called because the code is apparently trying to get a property from `undefined` (or `null`), in which case we try to decompile the bytecode to generate a more user-friendly error message.

(anonymous namespace)::BytecodeParser::parse()
  js::DecompileValueGenerator(JSContext*, int, JS::Handle<JS::Value>, JS::Handle<JSString*>, int)
    js::ReportIsNullOrUndefined(JSContext*, int, JS::Handle<JS::Value>)
      js::ToObjectSlow(JSContext*, JS::Handle<JS::Value>, bool)
        js::GetProperty(JSContext*, JS::Handle<JS::Value>, JS::Handle<js::PropertyName*>, JS::MutableHandle<JS::Value>) 
          js::jit::DoGetPropFallback(JSContext*, js::jit::BaselineFrame*, js::jit::ICGetProp_Fallback*, JS::MutableHandle<JS::Value>, JS::MutableHandle<JS::Value>)
            0x350351aa7094

Comment 4

[Ted Campbell [:tcampbell]]

We should use JSDVG_IGNORE_STACK in ReportIsNullOrUndefined if no debugger is attached. We still get the error message but will be something like |undefined is not a function| instead of |x.foo is not a function|. If user reloads with a debugger, they'd get the friendly message.

Comment 5

[Ted Campbell [:tcampbell]]

We should make sure to maintain the detail errors in jsshell though.

Comment 6

[André Bargull [:anba]]

Detailed error messages are used even when no debugger is attached, don't they? At least I assume they are, for example when websites attach a |window.onerror| handler to intercept uncaught exceptions and then send them to the server for recording.

Comment 7

[Ted Campbell [:tcampbell]]

They'd still get an actionable error, they would just need to look at the line of code and see the name of the binding. The reason for failure and the location would still be accurate. As well, Ion isn't able to support the expression de-compiler in general.

Comment 8

[Firefox Bug Husbandry Bot]

Migrating Webcompat whiteboard priorities to project flags. See bug 1547409.

Comment 9

[Firefox Bug Husbandry Bot]

See bug 1547409. Migrating whiteboard priority tags to program flags.