7.90 KB, patch
|Details | Diff | Splinter Review|
5.86 KB, patch
|Details | Diff | Splinter Review|
966 bytes, patch
|Details | Diff | Splinter Review|
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040210 Firefox/0.8 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040210 Firefox/0.8 When I open up my bookmark side bar (ctrl+b) and I go through my bookmarks the URL of the bookmarks isn't displayed in the status bar like it is if/when I知 using the bookmark menu. Would be great if there was some kind of consistency there. Reproducible: Always Steps to Reproduce: 1. Open up firefox 2. Open up the bookmarks sidebar 3. Hover over any bookmark Actual Results: The url of the bookmarks isn't displayed in the status bar. Expected Results: Display the URL in the status bar like it does when using the bookmark menu.
Bug 64892 is the same bug for Seamonkey.
tweak summary since this is an enhancement request. Adding polish keyword since we do this inconsistently for bookmarks.
would be nice. not going to hold. patches welcome
*** Bug 251737 has been marked as a duplicate of this bug. ***
Created attachment 153724 [details] [diff] [review] patch v1 bookmarksPanel changes basically copy bookmarksManager, and change click to double-click. History already had an onselect event so I just added the statusbar change there. The status bar remains the same until a page is loaded or link hovered, but I don't know how/where to change that or if it's worth it.
Comment on attachment 153724 [details] [diff] [review] patch v1 if it doesn't restore the previous value, this is better off not going in. Busted UI is worse than no UI at all. I don't even know what the best solution for these sidebars is (neither did hyatt, iirc, which is why this only works for the Bookmarks menu item at present
Created attachment 153779 [details] [diff] [review] includes onunload event After testing some more, I poorly worded that and didn't include everything. Anything that changes status bar text takes precendence over this(including the messages while a page is loading). In this new version I include an onunload event to reset the status bar to "Done" once the sidebar is closed -> the same behavior as unhovering a link. This gets rid of the behavior I was trying to describe above, where a URL from your bookmarks/history could get stranded until you performed any action which would update the status bar. Also selecting a history folder resets it to Done, unless anyone has a better recommendation for what a history folder should say in the status bar.
Comment on attachment 153779 [details] [diff] [review] includes onunload event Forgot comment: now the only way that this acts differently from, for instance, hovering a link is that a hover URL placed in the status text takes precedence over everything else until it's unhovered. My patch only changes the status bar until it's changed again -> it doesn't freeze it.
this is where the whole "right thing to do" becomes tricky. Changing the statusbar to "Done" isn't in itself sufficient, since there would be a previous status that isn't "Done" in a number of cases (i.e. if the content area is loading a page). Before writing more patches, we need to spec how this should interact with the status bar in all situations.
When fixing the here described problem, please _also_ remove the tooltips (I think that's how you call these yellow backgrounded text popups) that are only shown if the mouse is over a bookmark button in the bookmarks toolbar. If the URL is shown in the status bar they are not needed anymore. Further on they are not shown for bookmark folders and bookmarks within folders and nowhere in the bookmarks menu. So they are an inconsistency. So with fixing the here described bug, you should also remove these not needed inconsistent yellow tooltips!
(In reply to comment #10) I hope this bug also addresses the bookmarks toolbar, not only the sidebar!? I have set comment #10 here because my bug #251737 is set as duplicate of this bug. Here a copy of bug #251737: "If you move the mouse pointer within the bookmarks menu, the URL of the bookmark where the mouse pointer is currently over, is displayed in the status bar. But this does not work for the bookmarks toolbar. Reproducible: Always Steps to Reproduce: Actual Results: If the mouse pointer is over a bookmark-button, the URL should be displayed in the status bar." Please respond !!!
Comment on attachment 153779 [details] [diff] [review] includes onunload event comments given over IRC basically we need to figure out how this _should_ be handled (i.e. what does IE/Opera do, what do the Apple/GNOME HIGs say about this subject) onmouseover seems right, but it doesn't deal with the selection issue. as for removing the tooltips etc, I'm not sure that they're not a better solution in some cases, since they can provide more details about a bookmark than the statusbar. All this should probably wait until post-1.0 as time's pretty short to be speccing UI stuff.
(In reply to comment #12) > as for removing the tooltips etc, I'm not sure that they're not a better > solution in some cases, since they can provide more details about a bookmark > than the statusbar. If you think tooltips would be better, than they should be used everywhere where bookmarks are ... - in the bookmarks menu - in the bookmarks toolbar - in the bookmarks sidebar - in the bookmarks manager ... in order to keep consistency. Currently they are only shown for bookmarks that are directly in the bookmarks toolbar (and not in sub-folders.) Maybe if tooltips are used, then the status bar is not needed for displaying bookmark-URLs anymore, because the user does not need to have the URL displayed 2 times. But one disadvantage of the tooltips method is that some time is needed for waiting until they open, while the status bar is updated directly when "browsing" through the bookmarks menu. Whatever solution you prefer, please make sure to implement it uniform.
sorry for bugspam, long-overdue mass reassign of ancient QA contact bugs, filter on "beltznerLovesGoats" to get rid of this mass change
Bug 213163 just implemented this for the bookmarks *toolbar*.
would this nice-to-have be still in FF3 timeframe?
Deal, I'm gonna implement this the same way like Bug 213163, using the setOverLink function. This way I "don't have to worry" about restoring the status-bar to its original state (i.e. "Done"). Any objections?
Created attachment 302676 [details] [diff] [review] v2.2 Received a shout-out from Ace (mano) to add the same implementation for the History sidebar.
Created attachment 303046 [details] [diff] [review] v2.3 Fixed wrong header. Rephrased comments.
Created attachment 303051 [details] [diff] [review] v2.4 Rephrased comments (again). I forgot the mention that this patch also implements the same functionality for the history sidebar.
Comment on attachment 303051 [details] [diff] [review] v2.4 r=mano.
Comment on attachment 303051 [details] [diff] [review] v2.4 a=beltzner for 1.9
mozilla/browser/components/places/content/bookmarksPanel.xul 1.9 mozilla/browser/components/places/content/history-panel.xul 1.13 mozilla/browser/components/places/content/sidebarUtils.js 1.2
When hovering over bookmarks or folders in the bookmarks sidebar, nothing happens in the sidebar. Instead, tons of this error are logged in the error console: Error: tree.view.nodeForTreeIndex is not a function Source File: chrome://browser/content/bookmarks/sidebarUtils.js Line: 56
Steffen: Using the latest nightly build generates different results for me. I am *not* getting any errors, but I am experiencing some very weird behavior! More specifically: 1. Both sidebars do not load from the View->Sidebars menu. Only through keyboard shortcuts. 2. After hitting CMD+B to open the bookmarks sidebar, I have to click on a folder for the URLs to start showing up in the status bar. I believe that this should be filed as another bug all together.
Correction to number two (2) - After opening a sidebar, you much click inside its window somewhere to activate the status bar text.
Created attachment 304755 [details] [diff] [review] follow up for checkin Sorry! My bad.. I forgot to include the file where I did the QueryInterface to my diff!
(In reply to comment #31) > Typo: "clearURLFromStausBar". Fixed that. mozilla/browser/components/places/content/bookmarksPanel.xul 1.10 mozilla/browser/components/places/content/history-panel.xul 1.14 mozilla/browser/components/places/content/sidebarUtils.js 1.3
Works fine now.
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