613751 - It should be possible to move tab-modal alert prompts

Status: RESOLVED WONTFIX

(Toolkit Graveyard :: Notifications and Alerts, defect)

Description

[gadjo]

User-Agent:       Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b8pre) Gecko/20101120 Firefox/4.0b8pre
Build Identifier: 

It should be possible to drag&drop tab-modal alert prompts 

Reproducible: Always

Comment 1

[u88484]

Can you give an example of why a user may need to drag and drop a prompt?

Comment 2

[gadjo]

For example the page asks "Are you sure you want to submit this form?" and the prompt covers input fields I want to check to be sure that I want to send this form

Comment 3

[gadjo]

Of course I mean "move", not "drag&drop", it might be confusing

Comment 4

[Justin Dolske [:Dolske]]

I think this is going to be WONTFIX...

1) OS X already has immovable modal dialogs, and I've not ever seen a bug on that being a problem

2) You currently (Firefox 3.6) can't _scroll_ the page when a modal dialog is showing, so if the info you looking for on the page isn't visible, this would already be a problem. I've not seen bugs filed on this issue before.

3) Doing this kind of thing (requiring the user to check data in one window but answer in another) is rather dodgy UI, which is another mark against supporting that kind of use-case.

Comment 5

[[not reading bugmail]]

It should be movable if I want to see what is behind it in cases of needing to look at what is on the screen before clicking on something which might determine what you select.  Which happens a lot on the web.

Comment 6

[Jennifer Morrow [:Boriss] (UX)]

Can we just make the dialog's surface, as long as it's not a widget nor selectable text, be draggable on click & drag?  There would be no affordance for it, but if the user ever tried to move it they'd be pleasantly surprised.

> 1) OS X already has immovable modal dialogs, and I've not ever seen a bug on
> that being a problem

Most dialogs in OSX are moveable via dragging the top bar.

> 2) You currently (Firefox 3.6) can't _scroll_ the page when a modal dialog is
> showing, so if the info you looking for on the page isn't visible, this would
> already be a problem. I've not seen bugs filed on this issue before.

True, but if a widget on the page prompted the dialog, you're likely to be in the right place.  However, if you can't read text on the background anyway because it's too blurry, this bug is kinda wontfix before that gets fixed.

Comment 7

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

The only question I'd have is how dragging the prompt around would work once prompt text is selectable. (Bug 643712)

Comment 8

[gadjo]

> 1) OS X already has immovable modal dialogs, and I've not ever seen a bug on
> that being a problem

I don't know OSX, but in Windows (as I guess in Linux) all modal dialogs are movable, tab-modal prompts in Opera are also movable, and a lot of modal dialogs made with jQuery or similar tools are also movable. People get used to it, event if they use it only to have some fun and not to do something more constructive

> if the info you looking for on the page isn't visible, this would
> already be a problem. I've not seen bugs filed on this issue before.

If you take a look at comments in bug 613714 you'll see that people do want to see the page content, that's why this bug 613714 was created, it was not (only) performance issue

Wes Kocher (:KWierso):
> The only question I'd have is how dragging the prompt around would work once
prompt text is selectable.

In Opera the dialog's title bar is the handle for dragging (same like in modal dialogs in Windows, I don't think we need to reinvent the wheel)

Please don't WONTFIX :)

Comment 9

[Jennifer Morrow [:Boriss] (UX)]

(In reply to comment #7)
> The only question I'd have is how dragging the prompt around would work once
> prompt text is selectable. (Bug 643712)

Draggable top bar is a good bet.  That's fairly standard on OS's anyway, as Comment 8 points out.

Comment 10

[Zéfling]

Why WONTFIX  ? For confirm(), if the modal-box is on the text to confirm ? I have to cancel, then to move content (if it is possible), and begin again with certainty...

And, on Windows, the modal-boxes are movable.

Comment 11

[Dave Webber]

The modal dialogues in Safari (on Mac OS X and Windows) are also movable. An interesting point is raised in comment 7, but I think that could be resolved my having a visually distinct "handle" area by which the dialogue could be dragged around, akin to what is already present in Safari, and in Fx 3.6 on Windows.

Comment 12

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

(In reply to comment #11)
> The modal dialogues in Safari (on Mac OS X and Windows) are also movable. An
> interesting point is raised in comment 7, but I think that could be resolved my
> having a visually distinct "handle" area by which the dialogue could be dragged
> around, akin to what is already present in Safari, and in Fx 3.6 on Windows.

Make the glyph draggable, perhaps?

Comment 13

[Justin Dolske [:Dolske]]

(In reply to comment #6)

> > 1) OS X already has immovable modal dialogs, and I've not ever seen a bug on
> > that being a problem
> 
> Most dialogs in OSX are moveable via dragging the top bar.

No, these dialogs were all previously sheets (not windows).

Comment 14

[Dão Gottwald [:dao]]

Reopening as per comment 9 and bug 613714 comment 31.

Btw, Opera, the other browser with tab-modal prompts, supports this. I don't really see a reason not to do this, except that the current XUL layout might prevent it, which could mean "can't fix it just yet" rather than "don't want to fix it".

Comment 16

[Chris B.]

When you update the XUL layout, would it also be possible to remember the previous X, Y coordinate locations for the dialog, so that it will pop up in the same spot after you move it around?  It would be annoying for it to first appear center screen, then you move it to another spot, and when it pops up again it appears center screen again.  That would defeat the whole purpose of being able to move it.  If it can be coded to move, it should also be coded to remember the new pop-up location.

Comment 17

[Unknown W. Brackets]

(In reply to comment #16)
> When you update the XUL layout, would it also be possible to remember the
> previous X, Y coordinate locations for the dialog

Well, on the contrary, I've seen people get confused when things stay in the same place and they are somewhat "modal."  Imagine this:

1. User triggers a tab-modal prompt.
2. User moves prompt almost completely off page, to double check.
3. User closes the tab (which also happens to dismiss the now 99% hidden dial
4. Later, the user triggers a new tab-modal prompt.  But it's missing.  What happened?  Firefox is broken!

Actually, most of the time, modal dialogs end up appearing in the same place.  I think this is for good reason.  I guess it might be okay if it snapped-to page boundaries, but it seems needless.

-[Unknown]

Comment 18

[Chris B.]

(In reply to comment #17)
> (In reply to comment #16)
> > When you update the XUL layout, would it also be possible to remember the
> > previous X, Y coordinate locations for the dialog
> 
> Well, on the contrary, I've seen people get confused when things stay in the
> same place and they are somewhat "modal."  Imagine this:
> 
> 1. User triggers a tab-modal prompt.
> 2. User moves prompt almost completely off page, to double check.
> 3. User closes the tab (which also happens to dismiss the now 99% hidden dial
> 4. Later, the user triggers a new tab-modal prompt.  But it's missing.  What
> happened?  Firefox is broken!
> 
> Actually, most of the time, modal dialogs end up appearing in the same place. 
> I think this is for good reason.  I guess it might be okay if it snapped-to
> page boundaries, but it seems needless.
> 
> -[Unknown]

Understandable.....I'll be happy when I can move the tab-modal prompt (even if it stays center screen every time).

Comment 19

[gadjo]

requesting for 2.0 (hardblocker?)

Comment 20

[Justin Dolske [:Dolske]]

Not blocking. If it intolerable for you, flip prompts.tab_modal.enabled to get the old window-modal prompts.

Comment 21

[Siddhartha Dugar [:sdrocking]]

Perhaps if we were allowed to scroll on the page behind the prompt, then this problem would be almost solved.

Comment 22

[Matthew N. [:MattN]]

Bulk move to Toolkit::Notifications and Alerts

Filter on notifications-and-alerts-component.

Comment 23

[Jonathan Watt [:jwatt]]

Mass bug change to replace various 'parity' whiteboard flags with the new canonical keywords. (See bug 1443764 comment 13.)

Comment 24

[BugBot [:suhaib / :marco/ :calixte]]

The severity field for this bug is relatively low, S3. However, the bug has 18 votes.
:tspurway, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.