not prevent click events since Firefox 96

[gdh1995]

It seems Firefox 96 allows extensions to trigger native click behaviors.
See #3964 for reports.

Although this is not listed in https://www.mozilla.org/en-US/firefox/96.0/releasenotes/,
I think it's safe enough to skip preventing since Firefox 96.

This will fix #3964, fix #3979, fix #3986 and fix #3579 (comment)

====

Updated on 2022/08/09:

I was still curious about why it's Firefox 96 which began to behave differently, so according to the clue about Firefox 91.6.0esr in #4000, today I compared 91.5.1esr and 91.6.0esr and successfully found the root difference.

It's the bug fix of https://bugzilla.mozilla.org/show_bug.cgi?id=1739929 from Firefox team, and it's imported to make GMail work on it. Sadly to learn that complaints from us extension developers didn't make any contribution in it.

On Firefox 91.0, there're two chains handling click events on <a>:

1. The JS call enters Node::DispatchEvent
2. go to normal event-dispatching process

• 1. PopupBlocker::openAbused returned by PopupBlocker::GetEventPopupControlState(untrusted-click) is pushed
• 2. the enum can be seen on mozilla::dom::PopupBlocker::PopupControlState

3. call HTMLAnchorElement::PostHandleEvent -> nsGenericHTMLElement::PostHandleEventForLinks
4. call Element::PostHandleEventForLinks

• branch 4.a:
  • 1. if a click event is left-click and it has no modifiers, then Dispatch a non-trustable DOMActivate event
  • 2. if the DOMActivate event is prevented, abort
  • 3. enter Element::PostHandleEventForLinks again
  • 4. call nsContentUtils::TriggerLink(..., click=true, trusted=false)
  • 5. in nsDocShell::OnLinkClick creates an OnLinkClickEvent instance and dispatches it
  • 6. nsDocShell::OnLinkClickSync calls nsDocShell::InternalLoad, and go to nsGlobalWindowOuter::OpenInternal
  • 7. RevisePopupAbuseLevel(openAbused) calls IsPopupAllowed -> CanShowPopup
  • 8. WindowContext::CanShowPopup returns ! getPerf("dom.disable_open_during_load")
  • 9. the DOMActivate event and click events are marked eConsumeNoDefault
• branch 4.b:
  • 1. if a click event has modifiers, then return and continue dispatching

5. if result is eConsumeNoDefault, then stop
6. call "JS actors" including ClickHandlerChild, and it sends a json named Content:Click with modifier information

• 1. on a Firefox before v91.6 and v96, the event is ignored by configuration in BrowserGlue.jsm:ClickHandler
• 2. as for Firefox 96 and 91.6, the above bug fix added wantUntrusted: true into ClickHandler, so events work

On Firefox 96+, there's an extra logic:

1. if a event is dispatched during a listener of browser.runtime.Port::onMessage, then push openAllowed or openControlled

• 1. Unfortunately I didn't find the detailed code line

3. then during a normal event-dispatching process, although GetEventPopupControlState returns openAbused, it won't be pushed when building AutoPopupStatePusher
4. so RevisePopupAbuseLevel in the above 4.a.7 will return allowing.
5. then Firefox won't block "a plain click on <a target=_blank href> when dom.disable_open_during_load is true"

====

The dom.disable_open_during_load can be enabled by Privacy & Security -> Block pop-up windows on about:preferences.

[philc]

Great Dahan! I'll look at this shortly.

…

On Sat, Jan 15, 2022 at 3:05 AM, NPowDev < ***@***.*** > wrote: ***@***.**** approved this pull request. — Reply to this email directly, view it on GitHub ( #3985 (review) ) , or unsubscribe ( https://github.com/notifications/unsubscribe-auth/AAACDFRSVX7XONBBWSPD4DLUWFIIJANCNFSM5L34BGIA ). Triage notifications on the go with GitHub Mobile for iOS ( https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 ) or Android ( https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub ). You are receiving this because you are subscribed to this thread. Message ID: <philc/vimium/pull/3985/review/853538453 @ github. com>

[djpowers]

Code looks fine to me. I also pulled this down and can confirm that it resolved the issue for me in Firefox 97.

[philc]

@gdh1995 MVP -- thanks Dahan!

[ic-768]

This is still happening for me in firefox v.96 and vimium 1.67.1

[gdh1995]

@ic-768 Have you enabled privacy.resistFingerprinting on about:config? It will cause some issues and #4000 may fix it.

[xbsuser5143]

There's no problem in Firefox 97.0.1 and Vimium 1.67.1, but the issue (using F, af, or et opens links twice) is still happening in Firefox ESR 91.6.0 and Vimium 1.67.1, even when privacy.resistFingerprinting is disabled.

[gdh1995]

@xbsuser5143 Confirmed. This has only occurred since Firefox 91.6.0 esr (but not 91.5.0), so I've updated #4000 to fix this case.