1638872 - Google Docs, Sheets, and Slides: Control Click

Status: RESOLVED WORKSFORME

(Core :: DOM: UI Events & Focus Handling, defect)

Description

[Tony Cinotto [:tcinotto] (UTC-8)]

Attachment: Untitled.mov

on Nightly 78.0a1 (2020-05-18) (64-bit) when I command click using a mac to open the "right click menu" on Google Docs, Sheets, or Slides the menu will occasionally flicker too fast to take any action.

(Video attached: issue starts around the 7 second mark.)

Comment 1

[Tony Cinotto [:tcinotto] (UTC-8)]

Hi Julien, is this something you could help look into? In order to ensure stability for our users especially during COVID-19 it would be great if someone could look into this.

Comment 2

[Julien Cristau [:jcristau] (back August 18)]

Is it reproducible? if so, mozregression may help track down when it broke.

Comment 3

[Tony Cinotto [:tcinotto] (UTC-8)]

FYI this is on MAC OS 10.14.5

Comment 4

[Mike Taylor [:miketaylr]]

https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=32c22fdaf8c8a34aca65ecdfc6be30317a3dd480&tochange=d8726d18021eecb2e7f6768823672635a37012b9

Comment 5

[Mike Taylor [:miketaylr]]

[Tracking Requested - why for this release]: Breaking context menu for Google Sheets (mac only, it seems)

Comment 6

[Edgar Chen [:edgar]]

I will take a look.

The change in bug 1615732 is only enabled in the Nightly channel, https://searchfox.org/mozilla-central/rev/61fceb7c0729773f544a9656f474e36cd636e5ea/modules/libpref/init/StaticPrefList.yaml#1617.

Comment 7

[Julien Cristau [:jcristau] (back August 18)]

Not tracking as this is nightly only, but either way we should probably turn this off if we can't fix it soon.

Comment 8

[Edgar Chen [:edgar]]

I could 100% reproduce this,

1. press and hold control + mouse left button.
2. Wait for the menu showing up.
3. Move mouse left a bit to make it is not over the menu.
4. The menu will be closed as soon as I release the mouse button.

Comment 9

[Edgar Chen [:edgar]]

There are two different behavior comparing with Chrome and Safari, https://codepen.io/edgarchen-the-decoder/pen/ExVGRxB

1. Both Chrome and Safari fire contextmenu event with button=0, but Gecko still fire with button=2.
2. Both Safari and Gecko fire click event, but Chrome doesn't.

I suspect the difference in the context menu causes the behavior in comment #8.

Comment 10

[Edgar Chen [:edgar]]

(In reply to Edgar Chen [:edgar] from comment #9)

There are two different behavior comparing with Chrome and Safari, https://codepen.io/edgarchen-the-decoder/pen/ExVGRxB

1. Both Chrome and Safari fire contextmenu event with button=0, but Gecko still fire with button=2.
2. Both Safari and Gecko fire click event, but Chrome doesn't.

I suspect the difference in the context menu causes the behavior in comment #8.

It turns out fixing 1) doesn't help. But it is still worth fixing it to have a consistent contextmenu event with other browsers.

So it might because of the click event, but this issue could not reproduce on Safari which also fire a click event.
And then I tested Gecko and Safari with different userAgent:

• Safari could also reproduce the same issue with Firefox's userAgent.
• Gecko could NOT reproduce with Safari's userAgent.

It seems that Google Sheets does some special handler for Safari, so that same issue doesn't happen on Safari.

Comment 11

[Mike Taylor [:miketaylr]]

Yeah, I was wondering if that might be the case, similar to https://github.com/google/closure-library/issues/932.

We can reach out to Google, but first we need to find out where this particular context menu handling code is.

Comment 12

[Mike Taylor [:miketaylr]]

Ksenia, do you think you could find the relevant event handler for this issue (and see if maybe the unminified version is in ClosureJS)?

Comment 13

[Edgar Chen [:edgar]]

Thanks, I will also try if not dispatching click event would help.

Comment 14

[Edgar Chen [:edgar]]

(In reply to Edgar Chen [:edgar] from comment #13)

Thanks, I will also try if not dispatching click event would help.

No, suppressing click doesn't help, either. :(

Comment 15

[Edgar Chen [:edgar]]

(In reply to Edgar Chen [:edgar] from comment #14)

No, suppressing click doesn't help, either. :(

Another clue is Chrome could reproduce the same behavior in comment #8 if switching to Gecko's userAgent.

Comment 16

[Edgar Chen [:edgar]]

https://github.com/google/closure-library/blob/719529feafc9d60eecd2f620756d3e5cc84a9250/closure/goog/events/browserevent.js#L379-L392 might be related.

Comment 17

[Ksenia Berezina [:ksenia] on leave until 09/15]

(In reply to Edgar Chen [:edgar] from comment #16)

https://github.com/google/closure-library/blob/719529feafc9d60eecd2f620756d3e5cc84a9250/closure/goog/events/browserevent.js#L379-L392 might be related.

Thanks for investigating Edgar, this function is indeed related.

This is the minified version of the same function:

  , Df = Qd("Gecko") && !(Nea(Pd, "WebKit") && !Qd("Edge")) && !(Qd("Trident") || Qd("MSIE")) && !Qd("Edge")
  , Ef = Nea(Pd, "WebKit") && !Qd("Edge")
...

function Ko(a) {
    return Jo(a, 0) && !(Ef && Gf && a.ctrlKey)
}

(in https://docs.google.com/static/spreadsheets2/client/js/3004121820-waffle_js_prod_core.js)

If I change Webkit to Gecko, the context menu stops dissapearing in Firefox.

I guess we could create an issue/submit a PR to closure-library to handle Gecko the same way as Chrome in this case?

Comment 18

[Mike Taylor [:miketaylr]]

Filing an issue on closure would be a good first step, then we can raise that to the Docs team on our mailing list. It does make me wonder if there are other site that may break in similar ways though.

edit: this is Nightly-only for now, so we should find out hopefully via reports.

Comment 19

[Ksenia Berezina [:ksenia] on leave until 09/15]

Filed https://github.com/google/closure-library/issues/1075

Comment 20

[Mike Taylor [:miketaylr]]

Thanks Ksenia, I just sent an email to our GSuite mailing list.

Comment 21

[Edgar Chen [:edgar]]

I could not reproduce this anymore, I think the fix in closure (https://github.com/google/closure-library/commit/84a34d7d2c637cda55d9ed156cfd4d86f353487f) already appear in GSuite. Could we close this bug?

Comment 22

[Tony Cinotto [:tcinotto] (UTC-8)]

Attachment: test of command click.mov

Comment 23

[Tony Cinotto [:tcinotto] (UTC-8)]

Hi I'm still seeing this bug, Please see the video in the comment above.

Comment 24

[Edgar Chen [:edgar]]

Ah, right, I also see this bug on Google Doc, but doesn't see it on Google Sheets, and Slides.
It seems the fix isn't in Google Doc yet, let's wait a bit. Thanks!

Comment 25

[Edgar Chen [:edgar]]

I just try Google Doc again, I am not seeing this bug anymore.
I think the fix in closure already in Google Doc now.
Could you try again whether the bug is still reproducible? Thanks!

Comment 26

[Tony Cinotto [:tcinotto] (UTC-8)]

Attachment: 79.0a1 (2020-06-17) (64-bit) june 17google docs.mov

I'm still seeing the issue but less. Please see at the 5 seconds and 22-second mark.

Comment 27

[Edgar Chen [:edgar]]

One possible cause is the timing of releasing the ctrl key and the mouse button,
If the ctrl key release before the mouse button, then the ctrlKey property in mouseup event would be false, the script would think it is a "normal" mouse up then close the context menu, I could also sometimes reproduce the same thing on Chrome if I click ctrl and mouse button very quick.

To filter out the above tricky case, could you make sure that mouse button release before the ctrl key by pressing the ctrl key a bit longer to see if you are still seeing the issue? Thanks!

Comment 28

[Tony Cinotto [:tcinotto] (UTC-8)]

(In reply to Edgar Chen [:edgar] from comment #27)

One possible cause is the timing of releasing the ctrl key and the mouse button,
If the ctrl key release before the mouse button, then the ctrlKey property in mouseup event would be false, the script would think it is a "normal" mouse up then close the context menu, I could also sometimes reproduce the same thing on Chrome if I click ctrl and mouse button very quick.

To filter out the above tricky case, could you make sure that mouse button release before the ctrl key by pressing the ctrl key a bit longer to see if you are still seeing the issue? Thanks!

Thanks Edgar, that seems to work but I wonder if users will still experience this, if you're working very quickly and a power user I would imagine that you might not hold down the crtl key as long. I don't experience this on Chrome and didn't experience this a few months ago. It still seems like a regression in a user's experience.

Comment 29

[Hsin-Yi Tsai (she/her) | away [:hsinyi]]

Moving severity to S3 due to the regression change is in nightly for now.

Comment 30

[Markus Stange [:mstange]]

Is there more work that needs to be done on the Google Docs side to fix the remaining cases?

Comment 31

[Edgar Chen [:edgar]]

I experience the same thing on Chrome, so I don't think there is something we can do on Gecko side.

Comment 32

[Markus Stange [:mstange]]

Ok, then let's close this WORKSFORME based on comment 21.

Tony, could you file a bug on https://webcompat.com/ for the remaining issue?