Open Bug 14716 Opened 25 years ago Updated 2 years ago

don't popup new windows while mouse button is down


(Core :: XUL, enhancement)





(Reporter: Brade, Unassigned)



(Keywords: access, helpwanted)

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 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
Assignee: german → danm
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.
QA Contact: beppe → claudius
Assignee: danm → brendan
Severity: normal → enhancement
Summary: want popup windows' appearance disabled while mouse button down
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
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?

Assignee: brendan → german
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 ;-).

Assignee: german → brendan
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!
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.

how does this work in 4.x? at least on macos in 4.5, we do the right thing.
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.
right, of course, duh ;)

That means our solution needs to be XP somehow, but where it should go I haven't
the foggiest.
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,

Assignee: brendan → travis
Let's consider this post-beta 1 ...
Summary: want popup windows' appearance disabled while mouse button down → [RFE] want popup windows' appearance disabled while mouse button down
Target Milestone: M15
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, , which uses an annoying 
trick intended to make it hard for people to view his source.
Target Milestone: M15 → M16
Move to M16 for now ...
Flipping to peter to assign, I don't think I really own this.
Assignee: travis → trudelle
Summary: [RFE] want popup windows' appearance disabled while mouse button down → [RFE] don't popup new windows while mouse button is down
Another bug for Mr. Window - danm
Assignee: trudelle → danm
moving to m18
Target Milestone: M16 → M18
mass-moving all bugs to m21 that are not dofood+, or nsbeta2+
Target Milestone: M18 → M21
Target Milestone: M21 → Future
See also bug 40535.
To paraphrase someone, the future is now.  Can we get a more up to date prognosis 
for this bug? should just check to see if the mouse is down, if it is then it 
should use setTimeout to execute again later.
OS: Mac System 8.5 → All
Hardware: Macintosh → All
See also bug 72084, "There is no way to disable the context menu upon right-
Is this going to need bug 78248 - "[RFE] API to determine if a mouse button is
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.

Depends on: 78248
Summary: [RFE] don't popup new windows while mouse button is down → don't popup new windows while mouse button is down
Blocks: 243683
see bug 100180 too
QA Contact: claudius → jrgmorrison
Assignee: danm.moz → nobody
Assignee: nobody → jag
Blocks: 100180
No longer blocks: 243683
Priority: P3 → --
QA Contact: jrgmorrison → xptoolkit.widgets
Target Milestone: Future → ---
Assignee: jag → nobody
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.