239403 - pop-ups should be allowed in left-button onmousedown events

Status: RESOLVED WONTFIX

(SeaMonkey :: UI Design, defect)

Description

[Jesse Ruderman]

1. Go to http://diversity.uoregon.edu/main.htm
2. Click "Report Discrimination" in the black bar near the top of the page.

Result: the pop-up is blocked.
Expected: http://darkwing.uoregon.edu/~brt/ should open in a new window.

The page seems to have been generated with Dreamweaver.

Comment 1

[Jesse Ruderman]

Attachment: testcase

Comment 2

[Boris Zbarsky [:bzbarsky]]

Er.. does dreamweaver do this by default, or is this something the page author
hacked in?  Doing something onmousedown is pretty poor, since it prevents the
user from dragging off to cancel the action...

Comment 3

[Dan M]

Yes, it's another example of dumb HTML. It can't be a standard Dreamweaver
artifact because this can't be the only Dreamweaver page on the net. And let me
just say how *hilarious* it is that Mozilla pretty much works the way a browser
should, except it won't let you report discrimination at the University of Oregon.

Well, the capability is already coded. This behaviour can be changed simply by
changing the pref of allowed popup events. The question is whether changing the
default value is the right thing to do. I'm sure there exists a bad HTML
counterexample for every one of our controlled events. Automatically accepting
every one will weaken popup blocking. That said however, the mousedown event is
more likely than most and isn't so bad: it is the result of a direct user
action, after all.

But as Boris said, it's in a gray area because it's not second-guessable by the
user, like a click event. In my own mind I tend to classify it in the same
category as keyboard events -- touch the key and get the popup. I know we want
to stop somewhere short of enabling all of mousedown, mouseup, keypress, keyup,
keydown.

My inclination is to leave mousedown suppressed by default.

Comment 4

[Jesse Ruderman]

A mousedown event is a result of the *same* user action that triggers onclick. 
I don't understand your reluctance to enable pop-ups in onmousedown events given
that they're enabled in onclick events.

Comment 5

[Dan M]

I was about to write another one of my signature soliloquies waxing all elegant
about my position, but then I realized it wouldn't matter, since none of them
have ever changed anyone's mind.

Shorter version: click and mousedown, they're not the same. click is a
self-contained user end action. mousedown is supposed to be used at the
beginning of a selection action, for drag & drop or for buttons that give user
feedback when pressed. In theory they're altogether a different class of event.
In practice they are of course mistaken for each other by beginning programmers
as at the UO.

I'm not dead set against adding mousedown to the default list of allowed events.
But I'd much rather subscribe to a plan than suffer a knee-jerk reaction to
every example of questionable event usage that a horde of dedicated web surfers
can uncover given time and resources.

I guess it boils down to a decision of whether to make the default set
restrictive or loose. There's a good argument for loose, especially in Firefox,
where the blocker is on by default. So what's the default allowed set, then? We
have to add mouseup as well, since that's a more legitimate user end action
event than mousedown.

Is that it? Are there more? In my opinion the important ones are (timers), load,
unload, focus, blur, mousemove, mouseover, mouseout, and yes, error (because of
bug 239404). Maybe everything else should be allowed by default.

Comment 6

[Jesse Ruderman]

Dragging triggers document.onclick in addition to document.onmousedown, even if
you drag out of the window, so you can't use dragging to argue that onclick
pop-ups should be allowed while left-button onmousedown pop-ups should be
disallowed.

We have a short list of user actions that are allowed to trigger pop-ups:
left-clicking within a web page, pressing enter, maybe pressing space, maybe
using an accesskey.  There might be several events corresponding to a single
user action, but that doesn't make it any easier for sites to evade pop-up blocking.

Comment 7

[Dan M]

Thank goodness I didn't go for the longer argument.

OK. But I don't see this as a full response to my statement. You seem to be
picking at the fleshier bits and leaving the meat alone.

I just tried it. Click and drag. You get mousedown, then mouseup. click doesn't
show up even after releasing the mouse, if you move it a little before
releasing. I can certainly use drag and drop as part of my argument and it was
at best only part of my argument. The rest has gone unanswered, especially the
main point.

I don't quite follow where you're going with your final paragraph. Are you
arguing for a restrictive default set, or heading off in some other direction
without leaving me any signposts?

Comment 8

[Boris Zbarsky [:bzbarsky]]

> Dragging triggers document.onclick in addition to document.onmousedown, even if
> you drag out of the window

That's a bug, if true.  Please file it, if it's not filed already.  Dragging
outside the window should absolutely cancel the click event.  In fact, any
dragging at all should really cancel click events, except we have this view
capture crap going on.

Note that as far as I know right-clicks fire onmousedown (but not onclick).  Or
did we prevent them firing both?

Comment 9

[Jesse Ruderman]

damn and bz, I should have been more clear when I said "dragging".  I didn't
trigger drag-and-drop with my test; I just moused down in the window and moused
up outside of the window.  I tested with data:text/html,<body onclick="alert(5)">.

danm, I couldn't tell what your main point was.  If your main point was that the
default should be a blacklist, we've been through that in bug 197919 (see e.g.
bug 197919 comment 29).  I'm still arguing for a restricted set of user actions
that are allowed to create pop-ups by default.  But I see no need to block some
events triggered by a single user action while allowing others.

bz, onmousedown does fire for right-clicks.  So if onmousedown were allowed to
trigger pop-ups, it would have to be restricted to left-clicks in the same way
that key events are restricted to enter and space.

Comment 10

[Boris Zbarsky [:bzbarsky]]

> I didn't trigger drag-and-drop with my test;

Right.  That should not matter for purposes of cancelling the click event.

Comment 11

[Dan M]

Well here we are, as far as I can tell: Jesse, you want mousedown to be treated
like click because you think they're similar. I think they're fundamentally
different. A compromise which makes sense to me is loosening up the default
restrictions to include events like mousedown and mouseup, and perhaps several
others. We disagree there as well; I believe you feel this way only about
mousedown. This makes; I think I can truly say that it actually makes no sense
to me. And there we are. Ready for input from more people, I suppose.

Comment 12

[Dan M]

I have a counterexample. Click any of the video download links (the "Standard"
and "Cable Modem" links) on ESPN's video archive page
http://sports.espn.go.com/espn/thisissportscenter/archive . It shows the video
in a new window, and it opens two identical windows in which to do this. Two?
Yes, it opens one window in the link's click handler, and another in the
mousedown handler. Why? Seems like a programming mistake. It's difficult to
track down where the mousedown handler is added because the script on that site
is deliberately obfuscated. But it's there. It's been there for months. I
suspect that even the site's authors can't fix it. Blocking new windows on
mousedown makes this site work properly, opening only one window.

To my mind, this example and the one for which this bug was filed, and a dearth
of other examples, put window-opening mousedown-handlers squarely into the
category of rare and misunderstood edge cases where you'll be wrong and right no
matter which decision you make.

I still think mousedown and click are unrelated. But seriously, I'm actively
soliciting opinions from other folks on this bug.

Comment 13

[Asa Dotzler [:asa]]

I'm certainly not an expert in this area, but I agree with dan that mousedown
shouldn't be thought of as being "close enough" to mouse click that we treat
them the same here. My vote is for supressing the pop-up unless the user
actually completes the full click action. As a user, who doesn't necessarily
know what's going on "behind the scenes", I don't expect a link to be followed
(or in this case, to spawn a new window) unless I actually complete a click. 

Comment 14

[Dan M]

I'm not seeing any love for this bug other than from Jesse. I am seeing some
dislike for it, and I'm getting some "be more aggressive, you big wimp." I don't
like this bug, and I really don't plan to implement it, and I'd object if
someone else were to implement it. So I'm closing it "won't fix" and letting my
Honest Flag fly.

Comment 15

[Boris Zbarsky [:bzbarsky]]

*** Bug 244948 has been marked as a duplicate of this bug. ***

Comment 16

[scratch]

would there be any way to fire onmousedown popups if the user completes the
click?  i know that changes the effective functionality of the page, but in most
cases, it's what the author intended anyway, and this would seem to be a
compromise that makes both camps happy.

Comment 17

[Dan M]

You're suggesting that if we get a window.open request in the mousedown handler,
and open is blocked in mousedown events, that we remember the blocked request
and try again when/if a mouseup event comes through for the same element, if the
webpage itself hasn't issued another open request of its own, and there have
been no intervening mouseups on other elements. It's probably feasible, but it
makes some assumptions about the webpage writer's intent that I think could as
easily be incorrect.

Comment 18

[Johnny Stenback (:jst)]

FYI, popups are now allowed from mousedown events, see bug 258499.

Comment 19

[Robert Parenton]

The patch for Bug 258499 was backed out, so mousedown popups are once again blocked.

Comment 20

[Phil Ringnalda (:philor)]

*** Bug 268093 has been marked as a duplicate of this bug. ***