window.getSelection() into a text input can trigger application crash for ESR builds
Categories
(Core :: Layout, defect)
Tracking
()
People
(Reporter: bugzilla, Unassigned)
References
(Blocks 1 open bug)
Details
(Keywords: crash, parity-chrome, testcase)
Reporter | ||
Comment 1•6 years ago
|
||
Reporter | ||
Comment 2•6 years ago
|
||
Reporter | ||
Comment 3•6 years ago
|
||
Updated•6 years ago
|
Reporter | ||
Comment 4•5 years ago
|
||
I just tried
http://www.gtalbot.org/BugzillaSection/SelectTextInput.html
with Firefox 74.0a1 buildID=20200118213721 and along with the steps to reproduce and the application in the tab crashed. So, this bug and the CRASH is STILL REPRODUCIBLE.
Reporter | ||
Comment 5•5 years ago
|
||
http://www.gtalbot.org/BugzillaSection/SelectTextInput3.html
with the steps to reproduce also caused the tab of Firefox 74.0a1 buildID=20200118213721 to crash.
Comment 6•4 years ago
|
||
(In reply to Gérard Talbot from comment #5)
http://www.gtalbot.org/BugzillaSection/SelectTextInput3.html
with the steps to reproduce also caused the tab of Firefox 74.0a1 buildID=20200118213721 to crash.
This doesn't crash anymore, at least on Ubuntu 20.04 with current Nightly and release, but with Firefox all text in the orange box disappears. Which seems unexpected.
Updated•4 years ago
|
I think it's a Chrome issue; getSelection().isCollapsed
returns true but .toString()
still returns a value. Selection is not expected to show the text control internal information per the current specification.
Reporter | ||
Comment 8•4 years ago
|
||
The application crashed with both tests when using Firefox 78.9.0 ESR under Linux Debian 10.9.
Comment 9•4 years ago
|
||
The application crashed with both tests when using Firefox 78.9.0 ESR under Linux Debian 10.9.
Thanks for checking that. Confirmed on Ubuntu 20.04.
Comment 10•4 years ago
|
||
Given that this apparently crashed for ESR 52.9.0 but didn't for 63.0a1 (presumably Nightly) it seems ESR builds in general are affected by this. I wonder if this only affects Linux.
Comment 11•4 years ago
|
||
Confirming this affects ESR 78.10.0-build1.
I've reproduced it on Windows 10 and macOS.
Here are two crash reports:
bp-e61c3a63-4f53-41d9-a1cf-7a1370210414 (windows)
bp-e9efb58a-dd9c-4f4c-95f2-da58b0210414 (mac)
Comment 13•4 years ago
|
||
oh, hmm, I was testing Nightly only.
Comment 14•4 years ago
|
||
I've reproduced using the following STR:
- Load http://www.gtalbot.org/BugzillaSection/SelectTextInput.html or http://www.gtalbot.org/BugzillaSection/SelectTextInput3.html
- Select some text from the orange-bordered input (I've used double click).
-- 95% of the times the tab crashes here. If it does not crash at this point then deselect the text, enter some random test within the orange-bordered input and select it once more.
Reporter | ||
Comment 15•4 years ago
|
||
I've reproduced it on Windows 10 and macOS.
Thank you, Cornel. This is something that I always want to do but can not: verify if tests are reproducible on Windows 10 and macOS.
Updated•4 years ago
|
Updated•4 years ago
|
Comment 16•4 years ago
|
||
(In reply to Cornel Ionce [:cornel_ionce], Desktop Release QA from comment #11)
Confirming this affects ESR 78.10.0-build1.
I've reproduced it on Windows 10 and macOS.Here are two crash reports:
bp-e61c3a63-4f53-41d9-a1cf-7a1370210414 (windows)
bp-e9efb58a-dd9c-4f4c-95f2-da58b0210414 (mac)
Thanks, also for the crash reports. They indicate the bug is in layout-code.
Updated•4 years ago
|
Comment 17•1 year ago
|
||
Sorry, it looks like this slipped past the radar of Layout triage folks when it was reclassified.
Unfortunately, the crash reports from comment 11 have expired, so there's no way to see what the crash was (Beyond comment 16's note that they were "in layout code").
I can reproduce the crash 100% reliably in a Windows 11 VM, using Firefox 78 ESR, but unfortunately about:crashes
tells me that the crash fails to submit. (Possibly we don't accept crash reports from builds that old anymore.) So I still can't see what the crash signature/backtrace was, darn. :)
Good news, though -- if I let that ESR version do its auto-update to version 102.11.0esr, I can't reproduce the crash anymore. So I think this has been fixed.
gtalbot or noni: if either of you can still repro with Firefox 102 or newer, please reopen. Otherwise I think we're OK to call this WORKSFORME based on my testing.
Updated•1 year ago
|
Reporter | ||
Comment 18•1 year ago
|
||
Daniel Holbert,
Sorry for not replying earlier.
When using Firefox 102.11.0 ESR under Linux Debian 11.7, no application crash but all of the text in the orange box disappears.
I would not be able to say, like Kagami is saying in #c7, if this is instead
a) a spec violation
and
b) a Chrome bug.
In my opinion, the entire text disappearance must be a bug.
Description
•