Closed Bug 1477527 Opened 6 years ago Closed 11 months ago

window.getSelection() into a text input can trigger application crash for ESR builds

Categories

(Core :: Layout, defect)

defect

Tracking

()

RESOLVED WORKSFORME
Tracking Status
firefox-esr52 --- wontfix
firefox-esr78 --- wontfix
firefox63 --- wontfix

People

(Reporter: bugzilla, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: crash, parity-chrome, testcase)

window.getSelection() can trigger application crash when the selected text has to write into the input text from which it came from.

2 reduced and self-explanatory tests
- - - - - - - - - - - - - - - - - -

HTML 4.01 strict DTD:
http://www.gtalbot.org/BugzillaSection/SelectTextInput.html

HTML 5:
http://www.gtalbot.org/BugzillaSection/SelectTextInput3.html


Relevant code
- - - - - - -

  <script type="text/javascript">
  function init()
  {
  if(document.forms[0] && document.forms[0].InputName && document.forms[0].InputName.addEventListener)
    {
      document.forms[0].InputName.addEventListener("select", CopySelectedTextIntoInput, false);
    };
  }

  function CopySelectedTextIntoInput(evt)
  {
  if(window.getSelection)
    {
      document.forms[0].InputName.value = window.getSelection();
    };
  }
  </script>

  <p>Instructions: text select/highlight by dragging with the mouse any part of the text in the orange-bordered input.</p>

  <form action="">
    <p><input type="text" name="InputName" size="32" value="Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua."></p>
  </form>

Actual results in Firefox 52.9.0 ESR buildID=20180626223325: APPLICATION CRASH

Actual results in Firefox 63.0a1 buildID=20180720220116: the whole text in the orange-bordered input disappears.

Expected results: the highlighted text replaces the whole text in the orange-bordered input.

Chromium 67.0.3396.87 and Opera 56.0.3013.0 (Edition developer; Chrome/69.0.3472.3) achieve expected results.

Notes
-----
- I searched for duplicates and did not find any: bug 85686 is not a duplicate
- If I try to select with the keyboard: as soon as I enter the input thanks to [TAB] key, the whole Lorem ipsum text disappears in Firefox 52 and 63: so it's not possible to select with the keyboard. With Chromium 67, I can keyboard-navigate to the select and text-select only 1 character
- I am using Linux Debian 9.5
- as strange as it may seem, I had this testcase since july 2005 or even before and it was triggering an application CRASH for Deer Park alpha 1 rv: 1.8b2 build 20050703 and Deer Park alpha 2 rv: 1.9a1 build 20050813 . So, it is possible that I had already reported this crash bug before ... although despite thorough search, I can not find my testcase anywhere in bugzilla bug reports.
It is important to note that Firefox 52.9.0 ESR and Firefox 63.0a1 are not affected in the same manner. 
Firefox 52.9.0 ESR crashes. 
Firefox 63.0a1 simply fails the test.

- - - - 

As edited right now, the summary is possibly not appropriate and not precise. window.getSelection() is probably not the cause of the crash or problem; trying to write into the same source (input text) by setting the value of input is most likely the trigger of the crash or problem.
It is possible that the correct component for this bug report should be instead "Layout: Form Controls".
> window.getSelection() can trigger application crash when 
> the selected text has to write into the input text from which it came from.

window.getSelection() can trigger application crash when 
the selected text has *_to be written back into_* the input text from which it came from.
Priority: -- → P3

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.

http://www.gtalbot.org/BugzillaSection/SelectTextInput3.html
with the steps to reproduce also caused the tab of Firefox 74.0a1 buildID=20200118213721 to crash.

(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.

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.

The application crashed with both tests when using Firefox 78.9.0 ESR under Linux Debian 10.9.

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.

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.

Severity: normal → --
Priority: P3 → --

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)

OS: Linux → All

What are the exact steps to reproduce?

Flags: needinfo?(cornel.ionce)

oh, hmm, I was testing Nightly only.

I've reproduced using the following STR:

  1. Load http://www.gtalbot.org/BugzillaSection/SelectTextInput.html or http://www.gtalbot.org/BugzillaSection/SelectTextInput3.html
  2. 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.
Flags: needinfo?(cornel.ionce)

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.

(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.

Component: DOM: Selection → Layout
Summary: window.getSelection() into a text input can trigger application crash → window.getSelection() into a text input can trigger application crash for ESR builds

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.

Status: NEW → RESOLVED
Closed: 11 months ago
Resolution: --- → WORKSFORME

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.

You need to log in before you can comment on or make changes to this bug.