When enabling retained layers (layout.display-list.retain = true) on Firefox 58.0a1 (2017-11-03) (64-Bit) on Mac built from https://hg.mozilla.org/mozilla-central/rev/e6d86b7284bae701700b9d300ee1476ebe5f3eed editing Confluence pages with tables becomes impossible or almost impossible. Expected: Editing pages with tables works like with retained layers turned off. What happens: When editing Confluence pages with retained layers turned on tables can completely vanish, clicking into them makes the cell or some of them appear shortly and vanish again. This can repair by itself but, at least for me always happens directly after starting to edit the page. After some time it can stabilize so the issue is not visible any more. I recorded a video showing the issue. During this video I start edit mode and from then on only click in cells of the tables. Confluence Version used is Version 6.0.7
Does this still reproduce on the latest nightly? I cant reproduce it on our internal confluence installation. Can you please try saving an offline version of the page that reproduces this issue and upload it here? Thanks!
WFM now on 58.0a1 (2017-11-05) (64-Bit)
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → WORKSFORME
Problem is back again with 58.0a1 (2017-11-06) (64-Bit) built from https://hg.mozilla.org/mozilla-central/rev/179dae92e4d794e7f45ad080ff01908c80691f31. Does not happen on every try but most of time times. If it happens it happens directly after entering edit mode. Also sometimes stabilizes after some time being in the interactive editor. I also could see this in safe mode. I would have expected for retained layers not to be active in that. I cannot reproduce this with retained layers turned off.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
I see something like this with Tree Style Tab (webext) STR: 1. Minimize sidebar width 2. Open ~72 tabs and pin them 3. Open ~13 unpinned tabs (should be scroll) 4. See as blinking close buttons and pinned tabs icons on focus
Just setting the dirtyRegion = visibleRegion when we try to invalidate a frame during building isn't sufficient, since our descendants might load an override dirty region. We need to also set mInInvalidSubtree to true to block those, and force us to actually rebuild the whole subtree.
Assignee: nobody → matt.woodrow
Attachment #8926201 - Flags: review?(mikokm)
Comment on attachment 8926201 [details] [diff] [review] caret-invalidation-full Review of attachment 8926201 [details] [diff] [review]: ----------------------------------------------------------------- LGTM.
Attachment #8926201 - Flags: review?(mikokm) → review+
Pushed by firstname.lastname@example.org: https://hg.mozilla.org/integration/mozilla-inbound/rev/574db20bdf3e Make sure we properly invalidate the entire frame subtree when detecting a caret frame change. r=miko
This fixed the bug for me thanks! Additionally, it fixed flicker for another page I still had on my list to report.
You need to log in before you can comment on or make changes to this bug.