Closed Bug 1441466 Opened 6 years ago Closed 6 years ago

[regression] Middle-clicking link (to open in new tab) blocked by pop-up blocker

Categories

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

59 Branch
defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 1004633

People

(Reporter: post+mozilla, Unassigned)

References

Details

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:59.0) Gecko/20100101 Firefox/59.0
Build ID: 20180222170353

Steps to reproduce:

Since recently (maybe 4 to 6 weeks), in some websites, when I middle-click some of the links, instead of opening the link in a new tab, the pop-up blocker information bar appears.

So far I have noticed this on heise, for example you can go to https://www.heise.de/newsticker/meldung/Domain-Pulse-Registries-sperren-proaktiv-und-hoffen-auf-weitere-Haftungsfreiheit-3977934.html and middle-click "Rekordzahl von Domains".


Actual results:

A pop-up blocker information bar appears.


Expected results:

A new tab should have been opened.

This happens for all links in the text body of news on this website; it does not happen for links in the sidebars or for links from the main page to the individual article.

I tried disabling my adblocker, that made no difference.

This is a regression; opening links has worked fine in earlier versions of Firefox.
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:60.0) Gecko/20100101 Firefox/60.0
20180226230123

(In reply to Ralf Jung from comment #0)
> This is a regression

I doubt it. I was able to reproduce this as far back as Firefox 29. There are also at least 2 other bugs about this, one 6 years old and the other 4 years old. Feel free to try to find the regression range though [1].

A few notes:
* This is specific to middle-clicking. Ctrl+click works fine.
* This is specific to third-party links (at least on the site provided as an example). The aforementioned "Rekordzahl von Domains" link is blocked, as is "Alliance for Creativity and Entertainment" on another page [2]. Links to the same domain are not blocked however.
* Third-party links on other sites are not blocked when middle-clicked. For example, "Austere Luminosity of Chinese Classical Furniture" on this Wikipedia page [3].
* Bug 745329 - it looks like this should be marked as a duplicate of it.
* Bug 1004633 - nearly identical, except Click+click doesn't work either.

(In reply to Boris Zbarsky [:bz] (no decent commit message means r-) from bug 745329, comment #8)
> The native popup blocker doesn't block "middle click".  It _does_ block
> attempts to call window.open() from inside middle click, though.  Is the
> page doing that (and calling preventDefault to prevent the normal Firefox UI
> handling of middle click)?

I think so, but please check. In the Inspector pane, click the [ev] button next to '<html lang="de">'. Expand the first instance of 'click'. It shows

function(t) {
  var e = t.target;
  "A" === e.tagName && /external/.test(e.getAttribute("rel")) && /^(http|\/)/.test(e.getAttribute("href")) && (t.preventDefault(), window.open(e.getAttribute("href"), "_blank"))
}


[1] https://mozilla.github.io/mozregression/documentation/usage.html
[2] https://www.heise.de/newsticker/meldung/30-internationale-Medienunternehmen-bilden-Allianz-gegen-Piraterie-3743059.html
[3] https://en.wikipedia.org/wiki/Science_and_technology_of_the_Song_dynasty
Has Regression Range: --- → no
Has STR: --- → yes
Component: Untriaged → Event Handling
Flags: needinfo?(bzbarsky)
OS: Unspecified → All
Product: Firefox → Core
Hardware: Unspecified → All
See Also: → 745329, 1004633
I am surfing that website for many, many years and have opened links from their articles regularly. I am pretty much always open links by middle-clicking (unless I'm using a touchpad). I am sure this used to work.

Given your tests with older versions, this means something changed in their website?

> In the Inspector pane, click the [ev] button next to '<html lang="de">'. Expand the first instance of 'click'. It shows

For me it shows

function(r) {
  if (a && this.removeEventListener(t, e, n), r.__target || Ae(r), c !== this) {
    var i = Object.getOwnPropertyDescriptor(r, "currentTarget");
    Object.defineProperty(r, "currentTarget", {
      get: function() {
        return c
      },
      configurable: !0
    })
  }
  if (r.composed || -1 < r.composedPath().indexOf(c))
    if (ke(r) && r.target === r.relatedTarget) r.eventPhase === Event.BUBBLING_PHASE && r.stopImmediatePropagation();
    else if (r.eventPhase === Event.CAPTURING_PHASE || r.bubbles || r.target === c || c instanceof Window) {
    var s = "function" === o ? e.call(c, r) : e.handleEvent && e.handleEvent(r);
    return c !== this && (i ? (Object.defineProperty(r, "currentTarget", i), i = null) : delete r.currentTarget), s
  }
}
> Given your tests with older versions, this means something changed in their website?

Probably, yes.

I'm trying to understand comment 1.  Are you saying you _do_ have a listener that looks like that?  If you do, then of course it would cause this behavior.  I'm not seeing such a listener, though...  (And I have middle button, so no way to test the behavior.)
Flags: needinfo?(bzbarsky)
Ah, a listener like the one described in comment 1 is there; it's just on document, not <html>.  From https://www.heise.de/assets/heise/heise/js/heise.js?a15eb42a1212eefec783 :

window.document.addEventListener("click",function(t){var e=t.target;0===t.button&&"A"===e.tagName&&"_blank"!==e.getAttribute("target")&&"external"===e.getAttribute("rel")&&/^(http|\/)/.test(e.getAttribute("href"))&&(t.preventDefault(),window.open(e.getAttribute("href"),"_blank"))})}

but this one checks for left-click specifically (see the 0===t.button test).  Just to check, is this problem still reproducible on this page?
> I'm trying to understand comment 1.  Are you saying you _do_ have a listener that looks like that?

Didn't you ask me to look for a listener like that?  You said I'd find something that looks like 

function(t) {
  var e = t.target;
  "A" === e.tagName && /external/.test(e.getAttribute("rel")) && /^(http|\/)/.test(e.getAttribute("href")) && (t.preventDefault(), window.open(e.getAttribute("href"), "_blank"))
}

but I did not.  I found something else instead.  Or maybe you were saying something else and I misunderstood?
> Just to check, is this problem still reproducible on this page?

The one I linked above?  No in fact not.  Did they change their website again?

Websites changing so quickly kind of makes debugging hard...^^
> Didn't you ask me to look for a listener like that? 

I think "Gingerbread Man" was saying he was seeing a listener like that, but I wanted to confirm my understanding there.

> Did they change their website again?

So far it's sounding like they did...
So as far as I'm concerned this can be closed as a duplicate of bug 1004633.
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:60.0) Gecko/20100101 Firefox/60.0
20180227100126

(In reply to Boris Zbarsky [:bz] (no decent commit message means r-) from comment #3)
> I'm trying to understand comment 1.  Are you saying you _do_ have a listener
> that looks like that?

There was such an event listener when I posted comment 1, but not anymore.

> Just to check, is this problem still reproducible on this page?

No. Nothing blocked when middle-clicking the links mentioned at comment 0 and comment 1.

(In reply to Ralf Jung from comment #8)
> So as far as I'm concerned this can be closed as a duplicate of bug 1004633.

That one is still reproducible, so let's.
Status: UNCONFIRMED → RESOLVED
Closed: 6 years ago
Resolution: --- → DUPLICATE
See Also: 1004633
Component: Event Handling → User events and focus handling
You need to log in before you can comment on or make changes to this bug.