Closed Bug 438909 Opened 17 years ago Closed 17 years ago

[Fx3] Disabled options in context menus of bookmark toolbar items - workaround in comment 14 (greyed, or grayed out)

Categories

(Firefox :: Bookmarks & History, defect)

Product:
Firefox
Component:
Bookmarks & History
Type:
defect
Priority:
Not set
Severity:
minor

Tracking

()

Status:
VERIFIED FIXED
Milestone:
Firefox 3.5

People

(Reporter: haftsnation, Assigned: mak)

References

Details

(Keywords: regression, Whiteboard: [regr: bug 403263])

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; pt-BR; rv:1.9) Gecko/2008052906 Firefox/3.0 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; pt-BR; rv:1.9) Gecko/2008052906 Firefox/3.0 If I right-click any item in the bookmark toolbar after I closing any tab, all of the "Open" options (Open, Open in new tab, Open in new window) and "Properties" are greyed-out and disabled. If I richt-click the item again it works fine. Reproducible: Always Steps to Reproduce: 1. Right-click a bookmark in the bookmark toolbar and select Open in a new tab. 2. After the page is fully loaded, close the tab. 3. Right-click any item in the bookmark toolbar. Actual Results: The "Open" options (Open, Open in new tab, Open in new window) and "Properties" were greyed-out and disabled. Expected Results: The context menu should open as it does before closing a tab, with every option enabled. I'm using Firefox 3 RC2 in Brazilian Portuguese.
Version: unspecified → 3.0 Branch
Confirmed on Windows XP.
Status: UNCONFIRMED → NEW
Component: Menus → Places
Ever confirmed: true
QA Contact: menus → places
This can be confirmed on FF3final under Ubuntu 8.04 (3.0~rc1+nobinonly-0ubuntu0.8.04.1) and Windows XP (Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9) Gecko/2008052906 Firefox/3.0) So this is not restricted to Windows OS only... See for further comments: https://bugs.launchpad.net/ubuntu/+source/firefox-3.0/+bug/229893
OS: Windows XP → All
Hardware: PC → All
Flags: wanted1.9.0.x+
Flags: blocking1.9.0.1?
Flags: blocking1.9.0.1-
OS: All → Windows XP
Hardware: All → PC
I have a screenshot to confirm that this does indeed happen: http://img79.imageshack.us/img79/7395/disabledcontextmenuitemfj9.png
Flags: blocking-firefox3.1?
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9) Gecko/2008061004 Firefox/3.0 Confirmed on OS-X 10.5.2
OS: Windows XP → All
Hardware: PC → All
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9) Gecko/2008052906 Firefox/3.0 See another screen shot at http://img388.imageshack.us/img388/5108/tabbugli9.png
Additional infos: this bug does _not_ happens if you create or close another tab before you perform the second right-click (when the context menu should be partially disabled). Workaround: open bookmarks with mouse middle-click or with CTRL+click to open in a new tab, or SHIFT+click to open in a new window Severity to minor, it's not a major loss of functions. HW -> PC, It was verified on Intel MacOSX. Need to be verified on a PowerPC.
Severity: major → minor
Component: Places → Toolbars
Keywords: qawanted
QA Contact: places → toolbars
Hardware: All → PC
Summary: Inactive items in the bookmark toolbar context menus after closing any tab → Inactive items in the bookmark toolbar context menus after you open and close a new tab from a bookmark in toolbar
Whiteboard: [reproducible on PowerPC?]
Version: 3.0 Branch → Trunk
somehow I doubt he meant to remove all those folks.
(In reply to comment #20) > somehow I doubt he meant to remove all those folks. > Let's hope.
this bug seems to be fixed in Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.8.1.16) Gecko/20080702 Firefox/2.0.0.16
Dominic, you are using Firefox 2.0. This has never been a problem in the 2.X series to my knowledge. I just checked 2.0.0.14 on Windows and could not reproduce it. It's a new bug for 3.0. This bug affects me about 15-20 times a day due to my workflow. It's not exactly a showstopper, but it's certainly my top annoyance with Firefox 3.0 by far.
I think Dominic is right. I remember having problems with this very bug in earlier versions of Firefox 2, and after some automatic update it was gone.
confirmed on: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1
I change the title, hoping the duplicates will be much less.
Keywords: qawanted
Summary: Inactive items in the bookmark toolbar context menus after you open and close a new tab from a bookmark in toolbar → [Fx3] Disabled options in context menus of bookmark toolbar items - workaround in comment 14 (greyed, or grayed out)
Whiteboard: [reproducible on PowerPC?]
(In reply to comment #14) Lucas, Since all the duplicates of this bug are being listed under your copy here, I am going to make this request of you: PLEASE upgrade the severity of this bug to at least NORMAL if not MAJOR. For those of us who make extensive use of the affected toolbar functions, this bug constitutes an EXTREMELY irritating loss of functionality. Furthermore, in spite of the fact that this bug is quite frequently duplicated, it seems not to have been worked on by anyone even a little bit. Downgrading this bug to 'minor' was, in my opinion, a grievous error. Please upgrade its severity so so someone will actually fix it--or at the very least, START working on it. Thanking you in advance, Phinneas > Additional infos: this bug does _not_ happens if you create or close another > tab > before you perform the second right-click (when the context menu should be > partially disabled). > > Workaround: open bookmarks with mouse middle-click or with CTRL+click to open > in a new tab, or SHIFT+click to open in a new window > > > Severity to minor, it's not a major loss of functions. > HW -> PC, It was verified on Intel MacOSX. Need to be verified on a PowerPC. >
(In reply to comment #32) Phinneas, Please read the severity rules: https://bugzilla.mozilla.org/page.cgi?id=fields.html#bug_severity Major: major loss of function Minor: minor loss of function, or other problem where easy workaround is present This bug is important, and I know it is irritating, but the severity rules should be followed, and can only be changed at the devs decision.
Flags: wanted-firefox3.1?
And, if you really want this bug to be fixed, the devs are flooded with hundreds of other things they need to do. If you want to fix, you can start coding.
I agree with Phinneas, this is the kind of thing that makes users go back to other browsers. I'm already familiar with using the middle-click right now, but I think most of the users are too lazy and won't push themselves any further. But Tyler has his point, and it's up to the devs to decide wich bugs are more or less important. As a regular user, I don't see any other bug than this (I submitted it :), and I wonder if this one is set to minor, maybe there are a lot of uglier bugs out there.
(In reply to comment #34) > If you want to fix, you can start coding. and (In reply to comment #36) > The best way to get work done on this, is to vote for it, keep an eye, and > code! > With all due respect, 99.5% of Firefox users AREN'T coders and you sure don't want them "start coding".
Then don't complain something is taking too long.
(In reply to comment #38) > Then don't complain something is taking too long. Excuse me? Could you please tell me where exactly I've complained about it taking so long? Let me save you the search: I haven't complained. I just pointed out that your "If you want to fix, you can start coding" comment isn't helpful because most users aren't going to start messing with code - and you really don't want them too either. Those of us that voted for this bug don't need your arrogance.
This bug has been flagged + wanted1.9.0x. That means that this bug is on the developer's radar. For a public release it is o.a. very important that a possible patch doesn't cause a bunch of other regressions. Is it possible to make a low risk patch? You can be sure that the team will weigh all possibilities, pros and cons, and emotional comments are understandable but won't help much to speed up the fix.
Component: Toolbars → Places
QA Contact: toolbars → places
Hardware: PC → All
Ria, thank you. I am using the workaround of comment #14, but I appreciate you pushing this obnoxious bug towards a fix. I remember this bug from an earlier Firefox (2.0?), but it was fixed on one of the first updates. I noticed that another annoying bug from the same early version of Firefox has also rssurected: the one where you close the browser, and restart it in fewer than about 10 seconds, you get an annoying error message something like "Firefox is already running, but is not responding". You then have to close that box, wait, then reopen it again. As I said, I bring this up here only because I remember both these bugs occurring in an early version of an earlier release, but they both vanished with the first tor second fix. I wonder, is it possible for Firefox 3 someone simply reused some old component of that version of Firefox for some reason, and that is why these two old-timey bugs are back again?
(In reply to comment #41) You were probably testing a 2.0 beta with the new Places component in spring 2006 (finally it was decided that Places was not yet ready for the Firefox 2 release). This new bookmarks & history component offers much more possibilities but the price can be performance problems on slower systems (slow startups and shutdowns). Although performance has much improved over time, see Bug 380307.
That's it! I remember this bug in beta versions of Fx2. So I thought it was fixed, but it was left aside :|
First: If you find the loss of functionality caused by this bug irritating, please do not forget to go to the top of this page and cast your vote for it to be fixed if you have not already done so. I think a lot of people simply have not done this one simple thing since the duplicate count for this bug is higher than the number of votes for this bug to be addressed. It has a very low number of votes, and as such, it has been downgraded to a "minor" problem. If it is not voted for, those with the ability to do so will not make a priority of fixing it. Second: Although I still argue that this bug should be addressed immediately since this is the only bug almost any Firefox 3 user is likely to notice, there are two workarounds for it: to open a link in a new tab, either: 1) hold control while clicking on the desired link or 2) click on the desired link with your middle mouse button (click wheel) if you have one--although this second approach does not work with all mouses. VOTE!!!
No longer blocks: 449170
Because the other bug has been closed as "duplicate", I will transfer this info here: I have already tracked down exactly which changeset introduced this behavior: http://hg.mozilla.org/mozilla-central/index.cgi/rev/421b8e80e454
Yes, it was already reported in comment 2
Whiteboard: [regr: bug 403263]
REMINDER: If you have not voted for this bug to be fixed already, please do so. There are 42 people on the CC list for this bug, and, oddly, only 31 votes for it to be fixed. For some strange reason, the developers seem to consider this bug (the only one the vast majority of users are guaranteed to be impacted by many times each day) unimportant. If you are reading this, then you went to the trouble of coming to this site and registering--so you might as well do the one thing you can do to move this extremely prominent bug to the very top of the to do list where it belongs. There are lots of bugs in Firefox, but this is probably the only one that will drive people away from it.
@Phinneas, Please do not criticize the developers for what work they decide to focus on or not work on. I think that most people can figure out to vote if they want this bug fixed without your annoying and pointless comments that have nothing to do with this bug. As said in comment 40, it is marked as wanted1.9.0.x, as well as possibly blocking 3.1. So please, stop posting these sort of comments with weak threats like: >There are lots of bugs in Firefox, but this is >probably the only one that will drive people away from it. Please only comment if you have something good to say. Thank you.
Of course, I didn't "threaten" anyone or anything. If I could fix the bug I would--but I can't, so I'm doing the only thing I can to nudge this ginormous bug towards a fix: making a case for voting for it, and reminding people of the importance of casting their vote if they haven't. Reporting, prioritizing, and helping fix bugs is of course the entire "point" of this site.
Assignee: nobody → mak77
Status: NEW → ASSIGNED
Depends on: 433542
Target Milestone: --- → Firefox 3.1
fixed by patch in bug 433542
Status: ASSIGNED → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
(In reply to comment #56) > fixed by patch in bug 433542 Outstanding! Thank you so much for your good work!
Status: RESOLVED → VERIFIED
Fixed and landed in Trunk
Flags: wanted-firefox3.1?
Flags: blocking-firefox3.1?
I'm still experiencing this issue in 3.0.3 (windows/x86)
3.1b1 here and the bug is gone.
This issue is fixed in the development release of Firefox (Trunk) and will hopefully be fixed in a 3.0.x release in the near future.
Flags: blocking1.9.0.4?
This doesn't meet the new, strict criteria for maintenance releases (security, stability, regression from previous maintenance release). This will be fixed in Firefox 3.1.
Flags: wanted1.9.0.x-
Flags: wanted1.9.0.x+
Flags: blocking1.9.0.4?
Flags: blocking1.9.0.4-
Isn't this a regression bug? It was working, and now it isn't.
"regression from previous maintenance release" This was filed with Firefox 3.0 and is therefore a regression from a major release, not a maintenance release.
Ok samuel, I agree (I had not been aware of the new criteria), so I think with 3.1 Beta1 out this is fine for 3.1.
Just updated to FF 3.0.4 here and bug is still present.
(In reply to comment #72) > Just updated to FF 3.0.4 here and bug is still present. That is because this will only be fixed in Firefox 3.1.0. See Comment #63. You can download Firefox 3.1 Beta 1, which I believe has this fixed in it.
Target Milestone: Firefox 3.1 → Firefox 3.5
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
Component: Places → Bookmarks & History
QA Contact: places → bookmarks
Marco, do we already have any automated test in this area?
Flags: in-testsuite?
not a complete test, browser_library_left_pane_commands.js tests some context menu options in Library, but not a lot of them.
You need to log in before you can comment on or make changes to this bug.