Closed Bug 1522455 Opened 6 years ago Closed 6 years ago

multi-line text selection is displayed over a sticky header

Categories

(Core :: Web Painting, defect, P2)

Product:
Core
Component:
Web Painting
Version:
64 Branch
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla68
Tracking Flags:
Tracking Status
firefox-esr60 --- unaffected
firefox64 --- wontfix
firefox65 --- wontfix
firefox66 --- wontfix
firefox67 --- wontfix
firefox68 --- verified

People

(Reporter: phennim, Assigned: mattwoodrow)

References

(Regression,
URL
)

Details

(4 keywords)

Attachments

(3 files)

text_selection_z-index_bug.gif
(deleted), image/gif
Details
reduced html
(deleted), text/html
Details
Bug 1522455 - Position sticky can be handled by the compositor, so should be considered an async AGR. r?miko
(deleted), text/x-phabricator-request
Details
Attached image text_selection_z-index_bug.gif (deleted) —

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:64.0) Gecko/20100101 Firefox/64.0

Steps to reproduce:

  1. Visit https://bugs.chromium.org/p/chromium/issues/detail?id=147
  2. Make a text selection that contains a "CR/LF"
  3. Scroll up so that the selected text goes under the sticky header

Actual results:

(Part of) the selected lines are rendered on top of the sticky header.

Expected results:

The selected text should not be visible when under the header.

URL: https://bugs.chromium.org/p/chromium/...
Has STR: --- → yes
Component: Untriaged → Layout: Positioned
OS: Unspecified → All
Product: Firefox → Core
Hardware: Unspecified → All

The STR seems to work fine for me using a Nightly on Linux.
It seems likely this is some kind of painting issue rather than Layout.

Component: Layout: Positioned → Web Painting

Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:66.0) Gecko/20100101 Firefox/66.0
20190125215013

I can reproduce this on Windows, based on attachment 9038793 [details] rather than comment 0:

  1. https://bugs.chromium.org/p/chromium/issues/detail?id=147
  2. Select from "tabs" to "2. Close the who"
  3. Using the mousewheel, scroll down.
Attached file reduced html (deleted) —
Status: UNCONFIRMED → NEW
status-firefox64: --- → wontfix
status-firefox65: --- → wontfix
status-firefox66: --- → affected
status-firefox-esr60: --- → wontfix
Ever confirmed: true
Keywords: parity-chrome, parity-edge
Keywords: regression
Has Regression Range: --- → yes
Flags: needinfo?(matt.woodrow)
Keywords: testcase

Can reproduce on macOS.

Priority: -- → P2

This is prioritized as a P2 with no assignee since January, could we either get an assignee or decide that this should be a P3? Thanks

No longer blocks: 1443027
status-firefox68: --- → affected
Regressed by: 1443027
Assignee: nobody → matt.woodrow
Flags: needinfo?(matt.woodrow)

Didn't have success making an automated test for this, even making a selection from JS still results in the correct behaviour.

Pushed by mwoodrow@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/267df62ca84e Position sticky can be handled by the compositor, so should be considered an async AGR. r=miko

https://hg.mozilla.org/mozilla-central/rev/267df62ca84e

Status: NEW → RESOLVED
Closed: 6 years ago
status-firefox68: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla68
Flags: qe-verify+

Hello,
Reproduced the issue using the test case from comment 3 with Firefox 66.0a1 (20190124214415) on Windows 10x64 and macOS 10.14.
The issue is verified using Firefox 68.0b12 (20190619234730) and Firefox 69.0a1 (20190624213657) on Windows 10x64, macOS 10.14 and Ubuntu 18.04.

Status: RESOLVED → VERIFIED
status-firefox68: fixed → verified
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: