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

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

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.

https://hg.mozilla.org/mozilla-central/rev/f3eb9d545987

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

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

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.