Page MenuHomePhabricator

[Regression?] In Safari, context menus don't get re-painted/closed upon selecting another node inside VE
Closed, ResolvedPublic

Description

Steps to replicate:

  1. Open VE for any page on Safari
  2. Select any item such as citation, link, image etc.
  3. Now select another element form the page

Expected Result:
The context menu of the previously selected item should be closed

Observed Result:
The context menu of the previously selected is still open, and also the context menu for the other one that I just selected.

Event Timeline

Ryasmeen created this task.Jun 28 2019, 9:38 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptJun 28 2019, 9:38 PM
JTannerWMF added subscribers: matmarex, JTannerWMF.

Hey @Ryasmeen, @ppelberg and @matmarex aren't able to reproduce this. Can you try again and coordinate with them?

JTannerWMF moved this task from Incoming to QA on the VisualEditor (Current work) board.

@ppelberg/@matmarex: I am using Safari Version 12.0.3 (14606.4.5) on MacOS Mojave.
Here is the video capture showing me following the same steps as described in the report:

Let me know if you need any other info to be able to reproduce it.

matmarex removed a project: Editing QA.

The additional context menus are not actually interactive, but just visual glitches?

Somebody using a similar OS/browser to your will have to experiment if there is anything silly we can do to make Safari repaint them (e.g. hiding and showing the context again). Alas, I don't have a Mac.

Hey @DLynch you may have to pick this one up

JTannerWMF reassigned this task from Ryasmeen to DLynch.Aug 9 2019, 5:33 PM
DLynch added a comment.Aug 9 2019, 6:51 PM

I can reproduce this, though it's a little inconsistent about when it happens. In my reproduction it's not required that I select another thing that triggers a context item -- many context items will leave their shadows behind to some extent. See:

My experience looks a little more lightweight than @Ryasmeen's -- I can't cause that distorted text, it's 100% the shadows as transparent overlays.

I can confirm that it's completely a rendering artifact, also.

Quirk seems to be with this CSS rule from OOUI

.oo-ui-popupWidget {
    filter: drop-shadow(0 2px 1px rgba(0,0,0,0.3));
}

Some quick testing suggests that adding -webkit-transform: translateZ(0); into that makes it do sufficient refreshing of the display to not leave the shadows behind. I'll write up a patch.

Change 529421 had a related patch set uploaded (by DLynch; owner: DLynch):
[oojs/ui@master] PopupWidget: use translateZ(0) on drop-shadows in wikimediaui

https://gerrit.wikimedia.org/r/529421

Change 529421 merged by jenkins-bot:
[oojs/ui@master] PopupWidget: use translateZ(0) on drop-shadows in wikimediaui

https://gerrit.wikimedia.org/r/529421

matmarex moved this task from Code review to QA on the VisualEditor (Current work) board.

Change 529624 had a related patch set uploaded (by DLynch; owner: DLynch):
[oojs/ui@master] Change to oo-ui-force-gpu-composite-layer for popupWidget

https://gerrit.wikimedia.org/r/529624

@matmarex: This task is in QA column but still reproducible it seems, is there something yet to be done for this to be testable?

@Ryasmeen This one needs to wait for testing until OOJS-UI gets updated, sorry.

@Ryasmeen This one needs to wait for testing until OOJS-UI gets updated, sorry.

I see, no worries! :)

Sorry, my mistake.

Change 529624 merged by jenkins-bot:
[oojs/ui@master] Change to oo-ui-force-gpu-composite-layer for popupWidget

https://gerrit.wikimedia.org/r/529624

Change 534517 had a related patch set uploaded (by VolkerE; owner: VolkerE):
[mediawiki/core@master] Update OOUI to v0.34.0

https://gerrit.wikimedia.org/r/534517

Change 534517 merged by jenkins-bot:
[mediawiki/core@master] Update OOUI to v0.34.0

https://gerrit.wikimedia.org/r/534517

ppelberg closed this task as Resolved.Sep 17 2019, 12:40 AM
Restricted Application added a project: User-Ryasmeen. · View Herald TranscriptSep 17 2019, 12:40 AM