Closed Bug 1550869 Opened 6 years ago Closed 5 years ago

Tapping an image on Twitter triggers unexpected selection (noticeable via surprise context menu + scrollbars)

Categories

(Core :: DOM: Selection, defect, P2)

defect

Tracking

()

VERIFIED FIXED
mozilla69
Tracking Status
firefox68 --- wontfix
firefox69 --- verified

People

(Reporter: dholbert, Assigned: TYLin)

References

(Blocks 1 open bug)

Details

Attachments

(2 files)

STR (no need to be logged in to twitter):

  1. In Fennec or Fenix, visit this tweet:
    https://mobile.twitter.com/FirefoxDevTools/status/1100852277911273472/photo/1

  2. Tap the image (to enter the image-only Twitter view).

  3. Tap the image again (now that you're in the image-only view).

ACTUAL RESULTS:
Some content is selected -- in particular:

  • a context menu appears (with e.g. "Copy" and "Select All")
  • Scrollbars appear (due to AccessibleCaret thumbs having been created just offscreen)

EXPECTED RESULTS:
Nothing should have been selected.

Note: this is part of the root cause of bug 1549292. (It won't help with the reduced testcases there, but it'll help with the bug's original STR on this twitter page.)

Summary: Tapping an image on Twitter triggers unexpected selection (and surprise context menu + scrollbars) → Tapping an image on Twitter triggers unexpected selection (noticeable via surprise context menu + scrollbars)
Flags: needinfo?(aethanyc)

It turns out that it's simple to trigger the bug. An undraggable image like <img draggable="false"> is sufficient.

Priority: -- → P2

This is a rework for the issue in bug 1516963.

The check "aFrame->IsFrameOfType(nsIFrame::eReplaced)" was added to
avoid breaking
editor/libeditor/tests/test_abs_positioner_positioning_elements.html
because it contains blockified (position:absolute) images in
contenteditable, and we don't want these images to use frame edge. But
for non-editable undraggable images, which have display:inline, we want
them to use frame edge to avoid being selected by a single-clicking.
non-editable draggable images use a different code patch to handle their
operations.

I think it easier to understand by checking the frame types directly. As
for images, we want non-editable images to use frame edge, but not those
editable ones because editor has its own logic to handle all the
dragging operations, etc. Using frame edge for editable images makes
them undraggable, and fails
test_abs_positioner_positioning_elements.html.

Assignee: nobody → aethanyc
Status: NEW → ASSIGNED
Flags: needinfo?(aethanyc)
Pushed by aethanyc@gmail.com: https://hg.mozilla.org/integration/autoland/rev/f3eb9d545987 Stop undraggable images from being selected by a single-clicking. r=emilio
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla69

Does this warrant uplift to beta or can it ride the trains?

Flags: needinfo?(aethanyc)

(In reply to Julien Cristau [:jcristau] from comment #5)

Does this warrant uplift to beta or can it ride the trains?

Hacking selection is always a bit risky, so I prefer to let this ride the trains. Thanks for the reminder.

Flags: needinfo?(aethanyc)

Hi!
Verified as fixed on Nightly 69.0a1 (2019-07-07) with Huawei Honor 8 (Android 7.0) and OnePlus 5T (Android 9).
I will mark this as verified on Firefox 69.

Status: RESOLVED → VERIFIED
Regressions: 1745435
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: