1516504 - Can not copy link

Status: NEW

(Core :: Layout, defect)

Description

[Eugen Konkov]

Attachment: __.jpg

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:64.0) Gecko/20100101 Firefox/64.0

Steps to reproduce:

I try to right click and copy link.

https://github.com/olifolkerd/tabulator/issues/1682#issuecomment-450091258
(see attached screenshot)


Actual results:

No menu item appeared to copy


Expected results:

'Copy link' menu item should appear

Comment 1

[Eugen Konkov]

FF v61 works fine

Comment 2

[Alice0775 White]

I can reproduce the issue on Nightly66.0a1 Windows10 and 60.4.0ESR as well.

And the problem start since Firefox59 release.

Regression window with UA spoofing "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:59.0) Gecko/20100101 Firefox/59.0":
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=a71d7c5dc7bb1549fd0fb720ec8e6cdae1941b27&tochange=b5a67fbf08051b7961cef6b9a8c8835fd3f87f50

Triggered by: Bug 1169740 Bug 1141863


The problem does not work Chrome and Edge.

Comment 3

[Liz Henry (:lizzard) (relman/hg->git project)]

Steven, can you help find someone to investigate (or give the bug a priority?) Thanks!

Comment 4

[Steven DeTar [:sdetar]]

Jason, could you help triage this bug real quick.

Comment 5

[Jason Orendorff [:jorendorff]]

I'll triage it tomorrow!

Comment 6

[Jason Orendorff [:jorendorff]]

I can't reproduce this in Nightly (67) or in Firefox 64.0.2. Right-clicking produces the expected "Copy Link Location" menu item, whether I'm logged into GitHub or not.

I'm using a Mac. Maybe it's Linux-only. nbp, can you reproduce this?

Comment 7

[Nicolas B. Pierron [:nbp]]

Testing on NixOS/Linux:

• Firefox 67.0a1 (2019-01-30): Cannot reproduce.
• Firefox 65.0: Cannot reproduce.
• Firefox 60.5 esr: Cannot reproduce.

Comment 8

[André Bargull [:anba]]

It's reproducible for me under Windows (Win7 and Win10), but not Ubuntu. When right-clicking on the comment date-time link, (most of the time) the normal context menu (so the one which is opened when right-clicking on a non-link part of the website) is opened. From time to time the correct context menu is opened, though. Interestingly when the wrong context menu is opened and I then select the inspect element context menu entry, the HTML element inspector displays an element in the actual comment, which may give a hint that somehow the internal cursor positioning is misplaced in some way.

It also seems to be affected by the overall vertical page size, for example right clicking on the date-time entry for the initial comment at [1] always works for me, but it doesn't work (most of the time) for the initial comment at [2]. The issue is also no longer reproducible when scripts are disabled. And I see a brief page scrolling movement when right clicking the date-time link at [2], so there could be some GitHub script running which attempts to recenter the page when right-clicking. Maybe this scroll action leads to a miscalculation of the context menu position and that's why the wrong context menu is opened?

[1] https://github.com/tc39/test262/issues/1898
[2] https://github.com/tc39/test262/issues/1997

Comment 9

[Jason Orendorff [:jorendorff]]

Hmm. If the behavior is flaky, the regression range might be incorrect.

Alice0775, how are the regression ranges found?

Comment 10

[Alice0775 White]

(In reply to Jason Orendorff [:jorendorff] from comment #9)

Hmm. If the behavior is flaky, the regression range might be incorrect.

Now, GitHub no longer works properly on Firefox51 and earlier even if UA spoofed.
So, there is no way to ascertain whether comments 2 was correct.

BTW, Now I can reproduce on 52.0esr with UA spoofing as 60.0.

Alice0775, how are the regression ranges found?

On Windows10,

Steps to reproduce:

1. UA spoof as Firefox60, if using 59 and earlier version.
   user_pref("general.useragent.override", "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Firefox/60.0");
2. Open https://github.com/olifolkerd/tabulator/issues/1682#issuecomment-450091258
3. Right click on "Dec 27, 2018"

Actual results:
There are no context menu "Open link ....", "Copy link location", etc...

New regression window:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=708de5d681d113649e8fac2a10a4a0c0eae8be43&tochange=8fae1fb3e02eef78e34aeafb662cbc54496521e1

Comment 11

[Jason Orendorff [:jorendorff]]

Emilio, please see comment 8. (I think the regression windows in this bug might be wrong because the STR are too flaky for a reliable bisection.)

Comment 12

[Emilio Cobos Álvarez (:emilio)]

I agree the regression window sounds weird (though might not be wrong). In any case it seems unlikely to be the root cause of the issue.

I could repro it on Miko's computer, and I think I see what's going on. I think GitHub is a bit racy here, or something of that sort. There may still be a bug to fix on our end though, but it's probably hard to figure out the root cause.

Here's what I found out and why I think it explains the bug. When I click repeteadly on the date from https://github.com/olifolkerd/tabulator/issues/1682#issuecomment-450091258, I can see (sometimes) the page jumps for a very very short moment. This is the underlying cause of the issue.

It jumps because they're probably trying to scroll to the comment's position with Javascript, intercepting the click event.

They're probably trying to do something like the following to account for the position: sticky header:

  targetComment.scrollIntoView();
  document.documentElement.scroll(document.documentElement.scrollLeft, document.documentElement.scrollTop - stickyBarHeight);

But they're somehow doing something asynchronous and we're catching the page in the first state, which is why the context click ends up targeting the part of the comment that would be under the mouse.

Does that sound a reasonable explanation?

Comment 13

[Emilio Cobos Álvarez (:emilio)]

Attachment: Testcase that sometimes shows the link scrolled to the original position (when _right_ clicking, not left-clicking).

Playing with this I came up with this test-case, that from time to time scrolls the link under the sticky header. Not sure that the time the fragment navigation happens is defined...

And not sure it's totally the root of the issue either, since context-click doesn't trigger navigation.

Adam, do we know someone from GitHub that could provide input here? Knowing if I'm very off-base would be helpful, providing feedback on what they're doing when you context-click the date would also be extremely helpful.

Comment 14

[Adam Stevenson [:adamopenweb]]

I only know Bryan Clark and he's on leave atm.

Mike do you have contacts at GH?

Comment 15

[Mike Taylor [:miketaylr]]

Not really... but I did see a tweet about their sticky headers (https://twitter.com/lukehefson/status/1090298275482095616), which points to https://github.com/joelhawksley as an engineer who worked on that. His email is linked in his profile, and might be able to point us at the right person if it's not him.

Comment 16

[Mike Taylor [:miketaylr]]

(I sent an email to Joel, hopefully he can find someone to comment if he's not the right person.)

Comment 17

[Kristján Oddsson [:koddsson]]

Hey there!

I'm a engineer at GitHub 👋🏻

It jumps because they're probably trying to scroll to the comment's position with Javascript, intercepting the click event.

We are indeed doing something like this. I haven't been able to really figure out the underlying issue with the jankiness when repeatingly clicking the permalink but I'm queued up to deploy a change that adds a check for the primary mouse button in the click handler. That should hopefully clear up the issue of not being able to right click the link for those that are experiencing it. I wasn't able to reproduce it myself however.

Comment 18

[Emilio Cobos Álvarez (:emilio)]

Hi Kristján!
(In reply to Kristján Oddsson [:koddsson] from comment #17)

We are indeed doing something like this.

I haven't been able to really figure out the underlying issue with the jankiness when repeatingly clicking the permalink but I'm queued up to deploy a change that adds a check for the primary mouse button in the click handler.

Thanks, that's helpful, nice to know I'm not very off-base :)

That should hopefully clear up the issue of not being able to right click the link for those that are experiencing it. I wasn't able to reproduce it myself however.

Nice, thank you!

I think the jump happens because you're not preventing the navigation (you're not calling event.preventDefault() on the handler), and thus Gecko queues a task to scroll to the anchor, which some times, it seems, can happen after you perform the scroll yourself.

Is there any chance I can know how you're scheduling the task to scroll to the element? Are you using requestAnimationFrame? setTimeout(.., 0)? Something else? That'd allow me to hopefully diagnose it and fix it.

Comment 19

[Neha Kochar [:neha]]

Adding ni for Kristján to respond to comment 18.

Comment 20

[Ryan VanderMeulen [:RyanVM]]

Mike, do we have contacts at Github we could try contacting to get this moving again?

Comment 21

[Mike Taylor [:miketaylr]]

Kristján still has a needinfo? here, but in the off-chance they see this, any response to Comment #18?

(If anyone has a line to Bryan Clark, now would be a good time to use it!)

Comment 22

[BugBot [:suhaib / :marco/ :calixte]]

Clear a needinfo that is pending on an inactive user.

Inactive users most likely will not respond; if the missing information is essential and cannot be collected another way, the bug maybe should be closed as INCOMPLETE.

For more information, please visit auto_nag documentation.