Closed Bug 262640 Opened 21 years ago Closed 6 years ago

Should be able to modify location (URL) in "Add bookmark" dialog (Bookmark This Page...) like when using "File bookmark" in Mozilla - cannot bookmark friendly URLs from redirected pages

Categories

(Firefox :: Bookmarks & History, enhancement)

enhancement
Not set
normal

Tracking

()

RESOLVED WONTFIX

People

(Reporter: stig, Unassigned)

References

Details

(Keywords: ux-consistency, ux-discovery, ux-efficiency, Whiteboard: UI proposal: attachment 391888, see comment 13)

User-Agent: Mozilla/5.0 (Windows; U; Win98; rv:1.7.3) Gecko/20040913 Firefox/0.10.1 Build Identifier: Mozilla/5.0 (Windows; U; Win98; rv:1.7.3) Gecko/20040913 Firefox/0.10.1 I miss this option very much from Seamonkey ("File bookmark"). Often when you go to an "unspecifed frontpage" (like "http://www.website.com/") of some site you are immidiately forwarded to some other address which /currently/ is used as the frontpage of the site (like "http://www.website.com/uk/entry.php"), but may not always be the frontpage of the site. When bookmarking this site you wan't to register the first adress in the bookmark. To do that now you have to edit the bookmark again *after* it has been created. It would be much better to be able to cut of the extra bit already while adding the bookmark. There are various reasons for websites behaving like this: * Bad practise:-/ * Language-dependent pages * Handling of login * Session-management in url * and problably a lot more reasons... Anyway, it's very common. Check http://mozillanews.org/ for a quick real-world example (I would classify this one in the "bad practise" category). BTW the dialog-box in Firefox is called "Add bookmark", but in the menu it is called "Bookmark This Page...". A little inconsistent? Reproducible: Always Steps to Reproduce: 1. 2. 3.
This is not something most people would do, or even realize that the homepage would differ. This would add unnecessary complexity to a dialog that is already too complex by some standards. There's a reason we removed it in the first place.
Status: UNCONFIRMED → RESOLVED
Closed: 21 years ago
Resolution: --- → WONTFIX
I've been looking for an extension adding this to the "Add Bookmark" dialog, but it doesn't seem to exist? I wonder if it's possibly for an extension to add this option to the existing dialog? I know nothing about whats technically possible with extensions, but if it's not possibly right now, could it be done possibly by changing something in Firefox' "Add Bookmark" dialog? I have an idea of you maybe could implement the location input-field in Firefox, but keep it hidden. Then people could activate it by a hidden pref or an extension? But then again - maybe this is the way it already is?
Chuonthis has been so kind to update his Openbook extension with this much missed feature: http://www.chuonthis.com/extensions/openbook.php http://update.mozilla.org/extensions/moreinfo.php?id=42 In my opinion it is easy to configure the Add Bookmark dialog to be a much more intuitive one, with this extension. Even when including the URL-box I wan't to have. Simply always keeping the "Bookmarks tree" open, makes the dialog much better. The little button to open this tree in the default dialog only makes the dialog quirky and harder to understand - in my opinion. In the name of simplicity and accesibility I would consider removing the "Recently used folders dropdown" from the default dialog. I didn't really get it was a "recently used history dropdown" until I saw what it was called in the Openbook configuration options. Well, wonder if anyone reads this now that the bug has been closed with WontFix? :-/
*** Bug 270901 has been marked as a duplicate of this bug. ***
*** Bug 279358 has been marked as a duplicate of this bug. ***
sorry for bugspam, long-overdue mass reassign of ancient QA contact bugs, filter on "beltznerLovesGoats" to get rid of this mass change
QA Contact: mconnor → bookmarks
1. Go to http://opensuse-community.org/ 2. You get redirected to http://opensuse-community.org/Welcome_to_openSUSE-Community.org Importance: Given how many sites do URL redirection to crappy and unstable URLs, but I want my bookmarks to still work in a few years, I routinely edit the URL when bookmarking. Having to manually go to the bookmarks manager is not an option, because it's too frequent. This is a regression. All browsers I've used for 10 years allowed that. I know this change was intentional and UI decision, but it was a bad idea. I need this field, and many other people like me. REOPENing Mike Conner wrote: > This is not something most people would do That is not an argument to remove it from *all* users.
Status: RESOLVED → UNCONFIRMED
Resolution: WONTFIX → ---
Assignee: vladimir → nobody
Status: UNCONFIRMED → NEW
Ever confirmed: true
And no, an extension is not a solution. Add Bookmark is the most basic feature set of a browser.
Whiteboard: wontfix?
Another detailed description of the problem, based on duplicate bug 518423 (Cannot use primary UI to add new bookmark for web pages with friendly URLs that are redirected): For any given web address (friendly URL) that is being automatically redirected to some other web address (complex URL), it is impossible to add a new bookmark for the friendly URL using the primary Firefox UI (main Browser UI). I ran into this again today and I find it unbelievable that FF forces me to bookmark this(!!!): - https://direkt.postbank.de/direktportalApp/application;JSESSIONID_direktportalApp=TN1GLl0T2jklYLtvNy34SqnpHWTl1jvhTfzw56vn1qpHvsvQkn09!-123453943?origin=reloadOpenerAndClose.jsp&event=bea.portal.framework.internal.refresh&pageid=login ...while practically preventing me from simply bookmarking this (!): - https://direkt.postbank.de It is driving me nuts that I have both the simple URL and the bookmark right in front of me (location bar, yellow star), yet I cannot bookmark the simple URL without wild workarounds of going through bookmark manager!!! The annoying user experience of the current workaround is nicely described in Bug 405795, comment 9: > Whenever I bookmark something in Firefox, I have to get paste the crippled > pop-up, then I go to Organize Bookmarks, search for my bookmark, and finally > change the URL and add a comment. ...and Bug 405795, comment 8: > ...having to go through the trouble of browsing around for what is trying to > present itself as being right in front of you and then bait'n'switching into > browseable hiding when you want to see twiddle the rest of the object props. STR (using another real-world example from Mozilla(!), one out of millions): While browsing the site, try to create a stable bookmark for: www.getfirefox.com (friendly, stable, short and memorable URL) One of the most basic everyday bookmarking tasks, so it should be simple? Actual Behaviour: a) friendly, stable, short and memorable URL (www.getfirefox.com) is automatically and instantly redirected to complex, instable, and non-memorable URL (which might change any time if the web site authors so please): 2009: redirected to http://www.mozilla-europe.org/de/firefox/ 2011: redirected to http://www.mozilla.org/de/firefox/fx/?from=getfirefox Like it or not, it's a fact with loads of current web sites, more often than not. Some more random examples: - www.gmail.com -> https://accounts.google.com/ServiceLogin?service=mail&passive=true&rm=false&continue=http://mail.google.com/mail/&scc=1&ltmpl=googlemail (no, I really don't want to bookmark that redirect!) - www.microsoft.com -> http://www.microsoft.com/en-us/default.aspx - en.wikipedia.org -> http://en.wikipedia.org/wiki/Main_Page b) cannot add a bookmark for the friendly, stable URL (www.getfirefox.com) from FF primary bookmarking UI (the star in location bar for bookmarking the current site!) - this bug! c) insufficient primary bookmarking UI makes the user bookmark the redirected, thus complex and instable URL, which can easily break the bookmark over time and make it useless. So in 2009, I was "forced" by FF to bookmark - http://www.mozilla-europe.org/de/firefox/ In 2011, I depend completely on the grace of mozilla programmers that are still redirecting the outdated complex URL to something which works: - http://www.mozilla.org/de/firefox/fx/ However, compared to user's original intention of bookmarking the friendly URL (www.getfirefox.com), this bookmark is still technically broken, since it doesn't take me to exactly the same URL where the simple bookmark URL (www.getfirefox.com) would take me now: - http://www.mozilla.org/de/firefox/fx/?from=getfirefox So in this case, Mozilla is loosing statistics on how often folks use www.getfirefox.com. In many other cases, the complex bookmark will either break completely or take me to an outdated page. d) furthermore, the insufficient UI can make it harder or even impossible to retrieve the bookmark, especially when redirection is to another domain with complex url and user only rembers original, simple domain: - I intended to create a bookmark for simple URL, www.getfirefox.com - FF forced me to bookmark some complex target page with a completely different domain(!) instead (2009 version): http://www.mozilla-europe.org/de/firefox/ - Later, user is likely to fail when trying to retrieve the complex bookmark while only rembering the simple URL (www.getfirefox.com): Typing "getfire" into location bar will *not* find the complex bookmark! Expected Behaviour: - provide some simple way of adding a new bookmark from primary UI for *any* given URL that the user needs to bookmark, including friendly URLs that get redirected to ever-changing complex target URLs More use cases: - Get rid of anchors after the fact - Provide an easy way of bookmarking main pages from sub pages: STR - say you have navigated your way to http://www.mozilla.org/about/manifesto.en.html - realize "Mozilla rocks", click star to bookmark, but you really want to bookmark www.mozilla.org only, not the current location! Easyly adding a bookmark for a simple URL (like www.getfirefox.com) is one of the most basic features of a browser: It is unbelievable that in the year 2011, FF is not able to handle such a simple task while dead-simple one-for-all UI solutions (that will not harm the reduced UI for simple users in any way) are on the table (see my next comment here, comment 13). Please remove the wontfix nomination from this bug, as it is an insult to users, including even simple users who just want to bookmark a simple URL.
Summary: Should be able to modify location (URL) in "Add bookmark" dialog (Bookmark This Page...) like when using "File bookmark" in Mozilla → Should be able to modify location (URL) in "Add bookmark" dialog (Bookmark This Page...) like when using "File bookmark" in Mozilla - cannot bookmark friendly URLs from redirected pages
Proposed solution: Solving this bug and a host of other related bugs (like bug 405795) could be as simple as this (mockup Screenshot of proposed UI): Attachment 391888 [details] Add a tiny [v] "more"-twisty (with or without caption) in the lower-left corner of existing "Edit this bookmark" dialogue. We already have exactly the same twisty in Bookmark Manager's bookmark properties, so this should be very easy to implement. Clicking "[v]" expands the bookmark dialogue, revealing all properties of the bookmark so that the user can edit them (including Location, this bug). Proposed behaviour: Whatever state the user has chosen (expanded vs. reduced dialogue), it will be remembered for the next time the dialogue pops up, in the same way the library properties panel remembers the state. So all types of users will always get what they want. Win-Win: No harm for simple users (we keep the current reduced bookmark UI unchanged by default), yet single-click in-place access to the so-called "advanced" properties (which are not so advanced at all imo, and should not all be hidden to begin with, but that's another discussion). The only detail which needs a bit of thought is location bar's bookmark star status for currently shown complex URL after editing of bookmark URL to become simple URL, but again: We already have that behaviour, and it all behaves as expected: > - load bookmark from bookmark's sidebar > - open properties dialogue from that bookmark's context menu > - edit bookmark Location/URL, confirm changes > -> location bar URL and content area still show the original location > -> yellow star turns white (as original/current location is no longer bookmarked)
Note that this bug is violating a number of UX principles: * ux-efficiency, ux-discovery Obviously, opening bookmark manager, searching for a bookmark that was already right in front of me, then change its location property and go back to where I started from is very inefficient for such an everyday task. Furthermore, it's not very discoverable, at all. Simple users, which perhaps devs are trying to protect from the so-called "visual bloat" of a tiny toggle button, will never be able to figure out how they can bookmark a friendly URL like www.getfirefox.com. So we are not helping anybody with our "reduced UI" because there is no link at all to the "full UI", so frequent use cases are simply impossible to perform. Not to mention the bang-your-head-against-the-wall experience for advanced users. *ux-consistency We are also somewhat inconsistent within our UI: - as described at the end of comment 13, we have a different, more complete bookmark properties dialogue for bookmarks from side bar (and some other variants elsewhere) - we also have the more-twisty in the reduced properties panel of bookmarks manager, but not in the star's reduced bookmark properties - inconsistent again. External inconsistency: - It's OK to to reduce long lists of properties (or whatever) to something more useful for the assumed average user. - But it's *not* OK that we don't offer any in-place link to access the full set of properties - Other external applications do this better: Windows File Properties dialogue has "Advanced" button, Windows categorized control panel (few categories) has link to "Classic view" with more fine-grained options etc... Finally, per Ben's comment 8, browser competitors do *not* have the problem of this bug.
Whiteboard: wontfix? → wontfix? [has simple UI proposal: attachment 391888, see comment 13]
Blocks: 405795
Hardware: x86 → All
Status: NEW → RESOLVED
Closed: 21 years ago7 years ago
Resolution: --- → DUPLICATE

How is this a duplicate of bug: 502418?
Issues are clearly pointing to different directions. This empowers users to edit new bookmarks properties at the moment of creation. The linked issue suggests a "simplified" bookmark creation process.

I agree with harogaston, this is not a duplicate of bug: 502418. This one adds the URL field (back) to the bookmark creation dialog so you can do what you want with it. Bug 502418 limits you to the "canonical" form.

I concur. Here, the user want to correct the URL before bookmarking.

Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---

There have also been quite a number of bugs DUPed against this one, so this feature request is valid and should really stay.

Status: REOPENED → NEW
Whiteboard: wontfix? [has simple UI proposal: attachment 391888, see comment 13] → UI proposal: attachment 391888, see comment 13

this is still a wontfix per comment 1, I don't see any UX hints or new data for which we'd want to do this now.

Status: NEW → RESOLVED
Closed: 7 years ago6 years ago
Resolution: --- → WONTFIX

The product team responsible for bookmarks has made a decision on this feature request.

Per our rules for engaging on Bugzilla:

No whining about decisions. If another project contributor has marked a bug as INVALID, then it is invalid. Filing another duplicate of it does not change this. Unless you have further evidence to support reopening a bug, do not post a comment arguing that a bug resolved as INVALID or WONTFIX should be reopened.

Continuing to reopen a feature request which was closed by the product owners is a violation of the above. Further changes to the bugs status will result in administrative action on your privileges to participate in the community.

This bug is now closed to commenting by non-contributors.

Severity: normal → enhancement
Restrict Comments: true

For the record, Emma has deleted comment 24.

You need to log in before you can comment on or make changes to this bug.