Tab crashes when using Caret browsing to select text in pdf
Categories
(Core :: Web Painting, defect)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr115 | --- | unaffected |
firefox124 | --- | unaffected |
firefox125 | --- | unaffected |
firefox126 | blocking | verified |
People
(Reporter: rdoghi, Assigned: emilio)
References
(Regression)
Details
(Keywords: regression)
Attachments
(1 file)
4.48 MB,
video/mp4
|
Details |
Found in
- Nightly 126.0a1 (2024-03-19)
Affected versions
- Nightly 126.0a1 (2024-03-19)
Affected platforms
- Windows
Preconditions:
Enable pdfjs.enableHighlightEditor - true
pdfjs.enableHighlightFloatingButton - true
Steps to reproduce
- Open any PDF in Firefox.
- Highlight any text.
- Undo the Highlight with Ctrl+Z
- Disable the Highlight tool.
- Enable Caret Browsing and click inside.
- Select Text with Shift + Right arrow.
Expected result
- The Text should be selected and the Highlight Floating button should be displayed
Actual result
- The Tab Crashes.
Regression range
Not a regression.
@Calixte, can you please take a look at this issue ? I think this might be caused by the new Floating button, I can't reproduce this issue if the Highlight Floating button is disabled.
Comment 1•10 months ago
|
||
Can you test in a nightly without bug 1860328? So a couple days ago. This could be a regression from that.
Comment 2•10 months ago
|
||
Actually I was able to reproduce
Simpler STR:
set pref accessibility.browsewithcaret = true
open https://uwaterloo.ca/onbase/sites/ca.onbase/files/uploads/files/sampleunsecuredpdf.pdf
click on the text, shift plus left or right arrow to select text
repeat until crash
Comment 3•10 months ago
|
||
:sefeng, since you are the author of the regressor, bug 1860328, could you take a look?
For more information, please visit BugBot documentation.
Updated•10 months ago
|
Updated•10 months ago
|
Comment 4•10 months ago
|
||
Given that this is also reproducible without highlighting, we can say that 124 is affected too (first version where we support caret browsing in PDFs).
Comment 5•10 months ago
|
||
The regressing bug landed in 126.
Updated•10 months ago
|
Comment 6•10 months ago
|
||
The bug is marked as blocking firefox126 (nightly). However, the bug still isn't assigned.
:bhood, could you please find an assignee for this tracked bug? Given that it is a regression and we know the cause, we could also simply backout the regressor. If you disagree with the tracking decision, please talk with the release managers.
For more information, please visit BugBot documentation.
Comment 7•10 months ago
|
||
I know Sean and Emilio are looking into this, assigning to one of them, feel free to re-assign.
Assignee | ||
Updated•10 months ago
|
Assignee | ||
Comment 8•10 months ago
|
||
Can you check if this is fixed once bug 1886506 lands and sticks?
Assignee | ||
Comment 9•10 months ago
|
||
(I couldn't repro this one)
Comment 10•10 months ago
|
||
Clearing my NI given we are waiting to see if bug 1886506 fixes this
Comment 11•9 months ago
|
||
(In reply to Emilio Cobos Álvarez (:emilio) from comment #8)
Can you check if this is fixed once bug 1886506 lands and sticks?
Rares are you still able to repro this in the latest nightly builds?
Reporter | ||
Comment 12•9 months ago
|
||
I was able to reproduce this issue in our latest Nightly 126.0a1 (2024-03-25) ID 20240325214523
Comment 13•9 months ago
|
||
I tested and for me this is fixed by bug 1887552, which just landed, I don't think it's made it into a nightly yet.
Can you re-test when you get a chance with the next nightly? Thanks.
Reporter | ||
Comment 14•9 months ago
|
||
This is Verified as fixed in our latest Nightly build 126.0a1 (2024-03-28).
Can someone update the tracking flags to fixed? or should we mark them as Verified directly ?
Updated•9 months ago
|
Updated•9 months ago
|
Updated•9 months ago
|
Reporter | ||
Comment 15•9 months ago
|
||
Updating the main status flag for this.
Description
•