415270 - bookmark properties dialog modal.

Status: RESOLVED INACTIVE

(Firefox :: Bookmarks & History, defect)

Description

[crf]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b3pre) Gecko/2008013004 Minefield/3.0b3pre
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b3pre) Gecko/2008013004 Minefield/3.0b3pre

The bookmark properties dialog is modal (the browser or other bookmarks can be interacted with while this dialog is alive).

This not only limits the usefulness of the properties dialog, for example, by preventing you from straightforwardly accomplishing the common task of copying the address of a site and pasting it into the properties, but it also unneccessarily holds hostage any other task you'd want to accomplish with the browser.

The preferences dialog used to be modal, if I remember correctly, and was changed. The same idea could be accomplished here.

http://en.wikipedia.org/wiki/Modal_window




Reproducible: Always

Steps to Reproduce:
1.Click on the bookmarks menu and right-click on a bookmark and choose Properties
2.
3.
Actual Results:  
The properties dialog appears, and is unfortunately modal

Expected Results:  
That the properties dialog not be modal.

I don't think there is a good reason for it not to be modal. You should be able to use the bookmarks menu, and even that bookmark, while it's properties are being edited.

The bookmark's properties could be changed (if the properties were edited by the user) only at the time that the modal bookmark dialog was dismissed.

If some part of firefox needed that bookmark in the meantime, it could use the current copy (for example, exporting).

Perhaps, if a user were editing a bookmark, and, coincidentally, for the current url of that bookmark the user clicked the "star icon" in the localon bar in order to edit the bookmark, it might pose a problem. In that case, I think a message popping up underneath the "star" should inform the user that the bookmark is currently being edited. Perhaps this dialog could even mention the particular window that is editing the bookmark -- the bookmarks properties window, and maybe firefox could even flash the non-modal window to call it to the attention of the user.

There may be other areas, such as places, where there might be competing interfaces for editing bookmarks. (But note that places is not modal, which suggests to me that at least some of the issues mentioned above were somehow resolved.)

Locking the UI for the entire program just because the user is editing a bookmark is the right solution to these problems mentioned above. That cure is worse than the disease. It shows not quite enough thought has been put into determining how the various UI components should interact with one another in the area of bookmarks.

Comment 1

[Shawn Wilsher :sdwilsh]

Bulk closing all UNCONFIRMED bugs dealing with places that haven't had any bug activity in over 120 days, have no votes, and are not enhancement requests.

If you are still experiencing this issue in Firefox 3.0 or later, please re-open the bug with steps to reproduce (if they were not part of the original comment).

Comment 2

[crf]

This still occurs with firefox 3

Comment 3

[Shawn Wilsher :sdwilsh]

confirming on all active branches

Comment 4

[Shawn Wilsher :sdwilsh]

need a ux decision on this

Comment 5

[Nochum Sossonko [:Natch]]

Shawn, matters are worse now because all the bookmark editing ui uses this modal version. There used to be two different dialogs, one was modal the other wasn't. When a website now calls window.sidebar.addPanel it now pops up the modal dialog, which IMO is bad...

See bug 61098 comment 202.

Comment 6

[Madhava Enros [:madhava]]

This dialog is pretty inaccessible at the moment, as well as being modal.  You can bring it up by right-clicking on a bookmark in the bookmarks toolbar, and also, allegedly, by right-clicking on a bookmark in the bookmarks menu on windows (a discussion to leave for another day).

What if, instead of making this probably not-the-most-used dialog modeless, we just brought op the Library with the bookmark in question selected and ready for editing when the user issues any of the commands that currently bring up the modal dialog?  We get rid of a legacy modal dialog, and bring up a modeless one that also exists and has the same functionality?

Comment 7

[Nochum Sossonko [:Natch]]

I don't think that's really an option, the user wants to make a small edit to a bookmark, not bring up the whole Library. There's perf issues with that (~500 ms to open the dialog vs. ~2-3 seconds to open the whole Library) and it's just an over-reaction, IMO.

There's nothing wrong with the dialog, just make it semi-modal or entirely non-modal. I see no point in keeping it modal, it doesn't need to block anything. There should just be a check that things haven't changed to the bookmark being affected when the ok button is hit.

Comment 8

[Shawn Wilsher :sdwilsh]

(In reply to comment #7)
> I don't think that's really an option, the user wants to make a small edit to a
> bookmark, not bring up the whole Library. There's perf issues with that (~500
> ms to open the dialog vs. ~2-3 seconds to open the whole Library) and it's just
> an over-reaction, IMO.
Then we should fix those performance issues.  Not providing the user with a better experience because of a fixable performance issue is not ideal.

Comment 9

[Martin Packer]

I'd observe that ~500ms to open a dialog with such little content is FOREVER. And echo that fixing the performance issues in this area is worth working on. And further that 2-3s, while still far too slow, is not so bad given how much data is coming back.

Comment 10

[Gervase Markham [:gerv]]

Bug 451915 - move Firefox/Places bugs to Firefox/Bookmarks and History. Remove all bugspam from this move by filtering for the string "places-to-b-and-h".

In Thunderbird 3.0b, you do that as follows:
Tools | Message Filters
Make sure the correct account is selected. Click "New"
Conditions: Body   contains   places-to-b-and-h
Change the action to "Delete Message".
Select "Manually Run" from the dropdown at the top.
Click OK.

Select the filter in the list, make sure "Inbox" is selected at the bottom, and click "Run Now". This should delete all the bugspam. You can then delete the filter.

Gerv

Comment 11

[Scott Anderson]

Confirmed for 3.5.6 for Linux Mint 8. Additionally, the "Bookmark This Page" dialogue cannot even be moved or hidden (it does not seem to own its own window). Clicking on the browser window to focus on it achieves the unexpected result of (prematurely) completing the bookmark editing. All of this makes it difficult to check the page being bookmarked for appropriate tags or description, as the dialogue obscures the browser window, especially when expanded to its full size. Is this a separate bug? I did search but still getting used to Bugzilla, this was the closest I could find.

Comment 12

[BMO Automation]

Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.