14716 - don't popup new windows while mouse button is down

Status: NEW

(Core :: XUL, enhancement)

Description

[Kathleen :Brade]

This is related to 14714 which has to do with selection behavior.
This bug is for the behavior of opening up windows.

I was loading http://www.netscape.com/ in apprunner and playing with selection.
While I was in the middle of making a drag selection (the mouse button was still
pressed), a new window popped up.

I think that new windows should not popup while any mouse button is down.
(Disclaimer: the term "windows" used above means "top-level window" or "windows"
in a Macintosh sense)

German:  can you make a ruling regarding whether windows should be able to be
popped up while the mouse is down?  If you feel that the current behavior is
acceptable, please mark this as invalid.  If you feel that the current behavior
should change, please indicate so and reassign to [e-mail].

Comment 1

[shuang (gone)]

I am in for german (he is way toooooo busy updating the specs) on this bug. I
talked to german and we all agreed that the current behavior here is wrong. A
new window should not popup while any mouse button is down.Reassign it to danm.
Thanks!

Comment 2

[Dan M]

Not much to go on from the description. So I imagine this window's opening was triggered
by the inopportune firing of some JavaScript timeout. I'm not sure what it means to freeze execution
of the JS thread at certain points in response to hardware conditions. Sending to Brendan for
consideration.

Comment 3

[Brendan Eich [:brendan]]

I don't know where to start.  There is no JS thread apart from the UI/layout
thread for DOM JS.  Is that helpful?  Danm, what's really going on here?

/be

Comment 4

[Brendan Eich [:brendan]]

Reassigning to German for UE advice.  Do we have a usability bug here?  I think
so, but others do not.  Please assign back and I'll find the right person to own
it (or give it to [e-mail] ;-).

/be

Comment 5

[german]

It is a usability bug in a sense that while the mouse is down no other
non-background activities should happen. E.g. it's OK  to show continued
progress on a progress meter, but opening windows should deferred until the
mouse button is released. Mousing down indicates the users is about to make a
controlling action and the system is supposed to 'listen', if you exucse my
sloppy wording. It would be great if we could fix that!

Comment 6

[Brendan Eich [:brendan]]

Ugh, this sounds like we need more modality: when selecting (and dragging? it
seems so), other events must queue up until the select or drag is done.  Cc'ing
some selection and drag gurus for advice.

/be

Comment 7

[Mike Pinkerton (not reading bugmail)]

how does this work in 4.x? at least on macos in 4.5, we do the right thing.

Comment 8

[Simon Fraser [no longer active]]

That's probably because in 4.5, we're not handling any events while the mouse is
down; we're in a while (StillDown()){} loop. In Mozilla, on the other hand, we
handle events continually while the mouse is down, so other stuff can happen.

Comment 9

[Mike Pinkerton (not reading bugmail)]

right, of course, duh ;)

That means our solution needs to be XP somehow, but where it should go I haven't
the foggiest.

Comment 10

[Brendan Eich [:brendan]]

Travis, can you sit on this while I'm on sabbatical (or better yet, fix it, or 
pass it to someone who can, once the XP EventLoop stuff is done)?  Thanks,

/be

Comment 11

[don]

Let's consider this post-beta 1 ...

Comment 12

[Jesse Ruderman]

Could we also disable alert()s and include "when the user has made a right-
click menu" to the list of times when things shouldn't pop up? See my friend's 
page, http://www.ben2.ucla.edu/~dabruin/index2.htm , which uses an annoying 
trick intended to make it hard for people to view his source.

Comment 13

[don]

Move to M16 for now ...

Comment 14

[travis]

Flipping to peter to assign, I don't think I really own this.

Comment 15

[Peter Trudelle]

Another bug for Mr. Window - danm

Comment 16

[Peter Trudelle]

moving to m18

Comment 17

[Peter Trudelle]

mass-moving all bugs to m21 that are not dofood+, or nsbeta2+

Comment 18

[Jesse Ruderman]

See also bug 40535.

Comment 19

[Steve Dagley]

To paraphrase someone, the future is now.  Can we get a more up to date prognosis 
for this bug?

Comment 20

[timeless]

window.open should just check to see if the mouse is down, if it is then it 
should use setTimeout to execute again later.

Comment 21

[Jesse Ruderman]

See also bug 72084, "There is no way to disable the context menu upon right-
click".

Comment 22

[:deanis74]

Is this going to need bug 78248 - "[RFE] API to determine if a mouse button is
pressed"?

Comment 23

[Brian 'netdragon' Bober]

Dean: Most likely, if there isn't any xpcom API for this. If there is a way to
determine that, then I would assume that 78248 would be marked invalid. Since it
isn't, then this bug should depend on that. It might be faulty logic, but that's
my opinion at least. If you can't detereming the mouse is down, then there is no
way to complete this bug. The solution would be, imho, to have one of the
classes in the beginning of the event path keep some flags on which mouse
buttons are down.

Comment 24

[OstGote!]

see bug 100180 too