Closed Bug 1238758 Opened 8 years ago Closed 3 years ago

Crash to desktop from javascript execution

Categories

(Core :: DOM: Core & HTML, defect, P5)

46 Branch
defect

Tracking

()

RESOLVED WORKSFORME
Tracking Status
firefox46 --- affected

People

(Reporter: mordocai, Unassigned)

References

Details

(Keywords: crash, testcase-wanted)

Crash Data

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:44.0) Gecko/20100101 Firefox/44.0 Iceweasel/44.0
Build ID: 20160107232323

Steps to reproduce:

First off, here are crash reports for 44 and nightly:
https://crash-stats.mozilla.com/report/index/2d078684-87bb-4234-977a-fbc1f2160111
https://crash-stats.mozilla.com/report/index/2cc17ab0-c59f-464e-b6ea-7bfbd2160111

So this is an unfortunate situation. This crash is completely reproducible but it is caused by a proprietary Angular.JS application that I am not authorized to provide the source code for.

I will attempt to provide as much information as I can, as this is halting our deployment of an angular upgrade.

It's hard to create an effective bug report with this situation.

Basically what we have going on is:

1. Angular JS 1.3 or 1.4(not 1.2, tested all 3) page with <input type="number" />, type a decimal into it like 13.37.
2.  Submit form containing above input.
3. Angular changes state to a new page, passing around the value of above input as it does so.
4. On new page a frozen tooltip shows up "Please select a valid value, the two nearest values are 13 and 14". The page will stay frozen like this forever until you perform some kind of input.
5. Perform input. Moving the mouse does not cause crash, but clicking or pressing a key does.

Notes:

As mentioned above, this only happens once we upgrade to angular 1.3/1.4 from 1.2. Not sure if that helps you at all. This also does not happen if we remove type="number" from the input element and deal with converting the string into a number ourselves.


Actual results:

In 44 branch the browser crashes to desktop and brings up crashreporter.
In 46 branch (nightly) the tab crashes and brings up the tab crashreporter window.


Expected results:

No crashing
To be clear, despite my user agent being iceweasel I actually downloaded the official firefox 44/nightly for the crash reports. I just use iceweasel as my normal day to day browser.
So i've been thinking about this while writing the bug report and here is my completely unsubstantiated hypothesis based on testing this in firefox and chromium:

1. Angular has tooltip popup for the <input type="number"> element when the value is not an integer (why angular?).
2. In chromium this pops up instantly after you type the invalid value, in firefox I don't see it at all until after submitting form.
3. I submit the form and angular rewrites the DOM with the new page.
4. In firefox (not chromium) the tooltip popop for <input type="number"> element now shows up, but the element no longer exists!
5. On performing some action that takes focus from the tooltip popup, the crash occurs due to destroying the popup but the element the popup belongs to no longer existing.

The crash is DEFINITELY occurring on the destruction of the popup though.
Can you use mozregression [1] to find out when this stopped working?

[1] http://mozilla.github.io/mozregression/


And Please, attach testcase to the bug report if possible. If not, Post publick URLs to reproduce the issue.
Flags: needinfo?(mordocai)
Keywords: crash
Crash Signature: [@ mozilla::IMEStateManager::SetIMEState]
(In reply to mordocai from comment #2)

> The crash is DEFINITELY occurring on the destruction of the popup though.

Would it be possible to get a non-proprietary reduction of the code that is causing the crash?
Component: Untriaged → DOM
Product: Firefox → Core
We really need a simple testcase here.
Severity: normal → critical
Keywords: testcase-wanted
(In reply to Loic from comment #5)
> We really need a simple testcase here.

Would you attach a reduction of the crasher to the bug so we can reproduce it?
Flags: needinfo?(mordocai)
See Also: → 1402364
Priority: -- → P5
Component: DOM → DOM: Core & HTML

Marking this as Resolved > Worksforme since there are no more crashes with this signature in the past 6 months.

Status: UNCONFIRMED → RESOLVED
Closed: 3 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.