Closed Bug 406646 Opened 17 years ago Closed 16 years ago

Clicking to open slow menu (e.g. Bookmarks) invokes first item in menu (e.g. "Bookmark This Page")

Categories

(Core :: XUL, defect, P2)

Product:
Core
Component:
XUL
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla1.9.2a1

People

(Reporter: hroo772, Assigned: roc)

References

Details

(Keywords: common-issue-, fixed1.9.1, verified1.9.0.11, Whiteboard: [see comment 202 before commenting])

Attachments

(7 files)

files needed to reproduce bug.
27.88 KB, application/x-gzip
Details
strace log
201.94 KB, application/x-gzip
Details
Yann's Bookmarks that lead to a similar bug
161.35 KB, text/html
Details
backup of ~2000 bookmarks (import via menu in "Organize Bookmarks")
374.52 KB, application/octet-stream
Details
fix
3.61 KB, patch
enndeakin
: review+
Details | Diff | Splinter Review
fix, backported to 1.9.1
3.61 KB, patch
Details | Diff | Splinter Review
fix, backported to 1.9.0.x
3.60 KB, patch
dveditz
: approval1.9.0.11+
Details | Diff | Splinter Review
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b2pre) Gecko/2007120307 Minefield/3.0b2pre Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b2pre) Gecko/2007120307 Minefield/3.0b2pre When minefield is started up initially, when clicking the bookmarks menu item, it should drop down the list of bookmarks. When I try to do this, clicking on the bookmarks menu item makes the 'add this page as bookmark' dialog come up. I have found that if I click a different menu item like tools, then moving to bookmarks, the list shows up fine. Also, after the bug happens once, for the rest of the session it doesn't occur. Reproducible: Always Steps to Reproduce: 1. Start a new session of Minefield 2. Click the bookmarks menu item Actual Results: Minefield tries to add the current page as a bookmark Expected Results: The list of bookmarks should show up
I've witnessed this on Eric's computer, and he has enough bookmarks that the height of the Bookmarks menu is about double the height of his screen, if that helps with a repro any.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b2pre) Gecko/2007120408 Minefield/3.0b2pre WFM; I can't reproduce this. Did you also test this in safe-mode? http://kb.mozillazine.org/Safe_Mode_(Firefox)
From some testing I did, I found that on a newly created profile, there is no issue. I feel like it has to do with the large ammount of bookmarks I have. The random thing I just found was that with this build: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b2pre) Gecko/2007120414 Minefield/3.0b2pre ID:2007120414 I havn't been seeing the problem occur, I'll see if there's a way to reproduce it with this build
Just another update, I've found that the issue isn't as easy to replicate but I found that the issue is still occuring but in more specalized cases. If there are only a few bookmarks, I don't see this issue at all. Another thing I found was that if firefox is started fresh, had its first page load then click bookmarks, the list shows as normal. If i start firefox, then while the first page is loading which is netvibes (a heavy ajax page), clicking bookmarks then usually causes the issue to occur. It seems if firefox is under a load getting a page when i click bookmarks, it will usually cause the issue of it trying to bookmark that page.
Component: Bookmarks → Places
QA Contact: bookmarks → places
I found that recreating my profile fixed this issue.
Status: UNCONFIRMED → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Resolution: FIXED → WORKSFORME
verified - wfm
Status: RESOLVED → VERIFIED
why is this resolved "works for me"? Please don't do that or it'll never actually get fixed.
If specific steps to reliable reproduce this can be provided, please do so and re-open. Otherwise, it will never get fixed anyway.
I get this frequently, so, when it happens, I can try to get whatever debugging information you'd like (as long as it's explained to me -- I'm not a programmer).
Steps leading up to what happens, exact steps, any extensions installed/running, size and content of bookmarks, etc. If our developers can't reproduce it they will not be able to debug it.
I'm a friend of the bug reporter. My interpretation of what happens is that when Eric went to click on the bookmarks menu, Minefield fired an onClick on the menu; then, when it took a long time to load, Minefield had "forgotten" about the first onClick and fired a second onClick to the item that Eric's cursor now rested on: Add Bookmark. This occured the first time Eric clicked the Bookmarks menu in every Minefield session. We attributed the problem to the Bookmarks menu taking a very long time to load. When we created a new profile and added just those bookmarks that Eric actually needed, the problem went away. This is why Eric set the status to WORKSFORME. The solution is to export your bookmarks, create a new profile, and, WITHOUT copying back your places.sqlite, import your bookmarks or just recreate them from scratch. If you still have this issue, crf, after doing that, please reply to this bug again and I'll bug Eric to reopen it if he can. The big problem with debugging this issue is that it involved building up a large collection of bookmarks, and we're not sure exactly what about our bookmarks SQLite file causes this issue. Because of the sensitive nature of many of the bookmarks, Eric is uncomfortable posting the file for all and sundry to download.
I tried in a totally NEW profile. The new profile had zero bookmarks, and the issue didn't occur. So I imported (using places' UI) my old bookmarks file into my new profile, and then when I restarted the issue DID OCCUR. Maybe it is something peculiar with my bookmarks, or it is just their number. My computer is rather old, so maybe, if it is race, it is easier for the issue to occur on an old computer. I am attaching the bookmarks file I imported into my NEW profile (bookBUmarks.html).
Before importing, did the profile contain the default set of bookmarks? Did you use the Import or the Restore function? I tried every possibility a few times (on a four years old Windows XP computer) but I couldn't reproduce.
Attached file strace log —
Before importing (I used the import function), the new profile I created did not contain any bookmarks at all (neither in the bookmarks menu, nor hidden somewhere in places). (I'm also using ubuntu linux 7.10.). If it's useful, here is an strace log when the program was attached to firefox. The bookmark issue happened during its running. strace -Ff -tt -p pidOfrunningFireFox 2>&1 | tee strace yourlogfile
This problem occurs for me as well, on both XP and Vista.
Hello, the following bug occurs to me on Firefox3 (it looks very similar to Eric's bug, but I'm not sure because I don't know what "minefield" is... sorry i'm not native English speaker): "Clicking Bookmarks menu sometimes tries to add current page as bookmark, OR tries to modify one of my bookmarks." OS: fresh install of UBUNTU Linux (last version: Hardy, which uses Firefox3 as default). Bookmarks in attached file. (I imported them from this html file) Remark: I don't have this problem with Firefox2 (on Ubuntu Gutsy) Best regards to Mozilla team and the bug reporters.
As this bug seems to be closed, I reported also in this one (which is open): https://bugzilla.mozilla.org/show_bug.cgi?id=438719
I'm seeing this bug sometimes, and just had 2 users in Live Chat today with it. It looks like if you click on a menu and you move the mouse before the menu is drawn it sends the first action in the list. I see this with the File menu and New Window.
Status: VERIFIED → UNCONFIRMED
Resolution: WORKSFORME → ---
This bug is also present in the "production" version (Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1). Unfortunately this happens more or less randomly. What I seem to have in common with the other users is the large bookmarks file (wow, a whopping 602 kb, and it's really a surprise what's sitting in there (icons, descriptions or parts of the websites, ... )) given the size I wonder whether the problem might only occur when the bookmars file has to be reloaded for some reason?
This bug seems to be the same on Windows and Linux ( Bug 438719 ). The Bug 418949 on Mac may be related.
Might it be, that this issue only happens if the bookmarks list is too long to fit into the window completely, so that the scroll arrows have to be displayed at the top and at the bottom of the list. Or might it be, that if loading the bookmarks menu (or maybe drawing it) lasts a specific amount of time, the 'add new bookmark' panel is displayed. I tried to move some of my bookmarks to a sub-folder of the bookmarks menu. Then the issue does not occur. So IMHO it must have something to do with the bookmark count or the time to load them.
I have this issue with the File menu as well sometimes, so while the arrows thing might help trigger it. It definitely happens when I try to mouse down before the menu is visible, which explains why most people that see it are in the bookmarks menu, it would take the longest to show.
My bookmarks list fits the screen. But the display time is a good bet. At least for me there's a near 100% chance for the error to occur when the bookmars menu entry is clicked for the fist time.
My bookmarks list also fits the screen. For me too there's a near 100% chance for the error to occur when the bookmars menu entry is clicked for the fist time.
I also have the following bug, that i think is connected: when i right-click on a web-page or a web-link, in order to get the context-menu, it sometimes immediatly activates one of the actions of the context-menu that should have appeared (for example "Change page order", or "AdblockPlus", or "open in new page", depending how fast i was moving my mouse), but without displaying the context-menu, and without any right-click nor left-click from me. I think "Majken Lucy Connor" found the correct explanation: if you click on a menu and you move the mouse before the menu is displayed, it sends the action in the list above which your mouse-button is released. (like if the menu was displayed just before we release our mouse-button, but too fast to be seen). Please can anyone confirm?
One simple solution for this bug would be to disable the possibility to select an action in the menus as long as we don't release the first click (the one which made the menu appear). Then we would have to click again on the action to select it. Regards,
With the History menu (go-popup) (which I made a little longer to 500 items) I see this kind of bug without moving my mouse. Occasionally it opens the Library window instead, which is indeed an item in the History menu. Once it starts to perform the wrong action, it can't stop anymore and only a browser restart helps. In one of the duplicate bugs I told when this problem started. So I started to use the History Submenus extension. When the History Submenus 1.2 extension that I used instead broke on trunk (Windows) a few weeks ago, I had to use the longer menu again but I haven't seen the problem since then. So maybe something fixed this on trunk but broke the extension? So in any case, it appears to be true that a long menu with a lot of items in it triggers this bug.
I think I understand the cause of the problem. When you start a new session, the menus are completely blank, and when you click on one menu button for the first time in that session, it generates the menu from the first down. As the list gets bigger, the first item there gets pushed up, until it overlaps the button. Then the system recognizes that the menu is to long and compresses it with a scroll part. But during that time when you click, the top item has technically already overlapped the button, and the system registers that you pressed not only the button, but also the item. But when you click and hold the button, your locking in that the button is the only thing you clicked. Holding it ensures that the the system cannot place any other items into the "Click" memory location, making the address "read only". When you just click, the system registers that you clicked the menu button, but you left the memory unlocked for the system to write that you also clicked the item in that menu. I'm not an advanced programmer, I'm just learning the basics right now, but I believe that this is what's going on. I could be mistaken. Somebody might have a better understanding and idea of the situation, I'm just speculating.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b1pre) Gecko/20081005 Minefield/3.1b1pre Today I saw this bug again (after a long time) in the history menu of a trunk build.
(In reply to comment #37) > Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b1pre) Gecko/20081005 > Minefield/3.1b1pre > > Today I saw this bug again (after a long time) in the history menu of a trunk > build. So, shouldn't we change the status to NEW then? I mean, there are plenty of people experiencing this issue and it's by no means a rare issue if you take the dup count into account.
Just got this while trying to click on a Live Bookmark on a Flash-heavy site. Went to the first entry instead of dropping down.
Same issue with all main bar menu not only bookmark on Firefox 3.0.3 for Linux with all pages with or without Flash. Please fix it.
(In reply to comment #40) Sorry, I mean only history and bookmark menu are affected.
Correction of my previous comment: sometimes the bug occurs even when I don't move the mouse. When: left-click on history or bookmark upper menus, or right-click on a web page, or on a web-link in a web page. (Firefox 3.03 on Ubuntu Linux)
reported for both Win and Lin
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows XP → All
Hardware: PC → All
Version: unspecified → 3.0 Branch
(In reply to comment #46) > *** Bug 462492 has been marked as a duplicate of this bug. *** I was going to suggest that as a duplicate of bug 404314; There would certainly appear to be an overlap between the two bugs.
bug 404314 appear more releated to context menu and is for Linux, could be related but it's a bit different
This bug 406646, never happened to me before just few days ago, but unfortunately, I can not say it is after I installed FF 3.0.3, but never with previous versions since the beginning of Firefox. In my case it occur only when I start a new page (not a new Tab) of FF and click for the first time in bookmarks, it ask me to save the page instead to give me the list of my bookmarks.
Once more, with feeling: Same issue with Firefox 3.0.3 on Ubuntu 8.10. First time I click on Bookmerks in the top toolbar, instead of dropping down my list of bookmarks, up comes the Add Bookmark dialog.
Once more, with feeling: Same issue with Firefox 3.0.3 on Ubuntu 8.10. First time I click on Bookmarks in the top toolbar, instead of dropping down my list of bookmarks, up comes the Add Bookmark dialog.
"I see this too!" comments do not help fix a bug. The issue is known. If you don't have any information that will help fix the bug, please refrain from commenting. Thank you.
I received this in email this morning: "It would appear that this bug happened when the user is using Firefox 3 and the program Kaspersky Antivirus / Internet Security 2009. It therefore seems necessary to confirm the various people who reported this bug if they use Kaspersky products. (Sorry for bad english, i'm French)." Can anyone that sees this bug confirm or deny that theory?
Denied -- I'm using Linux, not Kapersky Antivirus involved.
I have this bug using Firefox 3.0.3 on Windows XP SP3. I do not use any Kaspersky products. I have Symantec's Anti-Virus. My bookmark list is 330 KB.
Vista, no 3rd party AV. In any case, that would only provide a 3rd party way of making the menu draw slowly. This isn't happening just to the bookmarks menu either, so something could be making it happen more often with the bookmarks (like AV scanning the file before loading it) but I think it's just more likely that most people only use the bookmarks menu. Something is wrong with the behavior between clicking on the menu and the menu taking too long to draw.
Just to confirm my experience... Kaspersky AV is NOT installed but I am running Firefox 3.0.3 Andrew
This bug wasn't there in Firefox 2.0 at all. When Firefox 3.0 was first released, this was the first bug I saw (in the first day). I don't use Norton antivirus, so I don't think the antivirus app has anything to do with this bug.
I use Firefox3 in Ubuntu 8.04 and Ubuntu 8.10, and I reproduce this bug in both. (for Tracy Walker: I don't use any antivirus, like most of Linux users) This bug is very boring because clicking on Bookmarks is generally the first thing I do when starting using FF. All people in the CC list please don't forget to vote !
Someone must know this bug exists and has fixed it as the most recent 3.1beta1 (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b1) Gecko/20081007 Firefox/3.1b1.) does not show the error, I have the same bookmarks in the beta as in the production 3.0.3 that shows the error. I think it is the shear number of bookmarks that causes the error. I wonder whether someone found the bug and that's what fixed it in the beta or pure happenstance. I have Kaspersky Internet Security and Superantispyware, but these were installed after the bug first appeared.
I take that last comment back the bug just occurred in the beta build, after not happening the last 5 times I had tested it.
I think Lucy is spot on, performance is a contributing factor in this bug, especially if it only happens right after startup. Recently there has been some perf improvements checked in, so it may not be happening as often for those who have seen it. Dev might want to try to repro on a slow machine under stress (resource hog apps running), using a large bookmark (place.sqlite) file. I'll try on my low end 6 y/o XP box.
Mozilla/5.0 (X11; U; Linux i686; fr; rv:1.9.0.4) Gecko/2008102920 Firefox/3.0.4 This bug exists in Firefox 3.0.4 AND in Firefox 3.1b1 under Linux. This is a security problem when it occurs when a framework to complete is displayed. The page changes suddenly when the user does not want this. He can lost datas.
Having this problem in Firefox 3.0.4 in Ubuntu. I do have a lot of bookmarks, but divided into a series of folders so my main list is not long. I do not know if it is connected or not, but when I do need to bookmark a site, the bookmark saved window will not expand or collapse any folders.
Summary: clicking Bookmarks menu when minefield starts, tries to add current page as bookmark → clicking Bookmarks menu when Firefox starts, tries to add current page as bookmark
I have experienced same bug as Eric Flower reported on 2007-12-03. According to my experience with Mozilla 3.0.4 this bug happens when you click on "Bookmarks" menu the First time during the session no matter how long ago the session has started.
Am I the only one to have both this bug and Bug 404314 (bug when clicking a menu) ? Looks like they are related...
(In reply to comment #72) > Am I the only one to have both this bug and Bug 404314 (bug when clicking > a menu) ? > > Looks like they are related... No, I'm also getting frequent selections of the first menu item when I click a menu. But the Bookmark issue is the most noticeable I suppose.
Given that it's repeatably the *first* menu item that's activated, and given that this is worse when the computer is loaded down, I'm guessing that this is caused by the following... (at least on Linux) a) the fact that menus appear on mouse-*down* rather than mouse-up (on Linux) b) occasionally, the user might move the mouse a little after mouse-down, and then by the time the menu appears (particularly if it's delayed due to CPU load), the cursor is already over the topmost menu item. And this activates that menu-item. --> This bug appears. This is the behavior in all Gnome apps (e.g. nautilus, Gedit), and if I intentionally move the mouse a bit as I click menus, I can reproduce it reliably in other apps. Can anyone reproduce this bug without moving their mouse *at all*? If so, that would invalidate this theory... (but I'm guessing that most occurrences of this bug are caused by this mechanism)
(In reply to comment #74) > b) occasionally, the user might move the mouse a little after mouse-down, and > then by the time the menu appears (particularly if it's delayed due to CPU > load), the cursor is already over the topmost menu item. And this activates > that menu-item. --> This bug appears. from what i can tell i did some tests time ago, and is not related to moving the mouse, all menus open the first item when the menu is slow to populate, and that's on Windows too.
(In reply to comment #74) > > Can anyone reproduce this bug without moving their mouse *at all*? If so, that > would invalidate this theory... (but I'm guessing that most occurrences of this > bug are caused by this mechanism) I just verified this bug "without moving the mouse at all". This was on an IBM laptop, without a traditional mouse; I positioned the mouse pointer, then clicked the left mouse key on the keyboard. I have Firefox 3.0.4 on Windows XP SP3, and a large bookmark list.
(In reply to comment #74) Daniel, you are right and you are wrong. You are wrong : moving the mouse is not required to reproduce the bug. You are right : when a click is made, the menu appear with the first item superposed with the item of the bar menu. Then quickly, the first menu item placed itself under the item of the bar menu. When the load is (a few) high (Firefox 3.0 is needed of a lot of CPU power), the menu has no time to place it under the bar and the mouse validates the first item. So I think that the fixing could be done by waiting that the first item is displayed under the bar or, better, waiting that another click should be required.
For some users, they may be seeing bug 454693 instead.
Keywords: common-issues+
While my computer is at a 2% CPU load I can click the bookmarks menu reproducing this bug and my CPU load rises by no more than 5%. I can also confirm that the bug occurs while clicking without moving the mouse.
Depends on: 454693
Also, has anybody taken into account the amount of stuff placed onto Firefox, like extensions, themes, plugins, content in the bookmarks bar and the others? I spoke with a relative of mine, and he says that these could also be factors. He uses Firefox 3, on a slow computer (compared to those made today), and has yet to get this error. He has very little in bookmarks, as well as everything else.
I think that CPU load is high in a very short time, probably due of Firefox itself (very hungry of power). Yes I have too a big list of bookmarks (126 K). Firefox 3.0 is not efficient to manage this list. A better database manager should be needed.
Here's a backup of 2000 bookmarks. I can reproduce this bug using this file by doing the following... 0) Start with a fresh profile 1) Bookmarks | Organize bookmarks 2) Import and Backup | Restore | Choose File (& pick this attachment) *Note: This import takes about 20-30 seconds to complete on my machine. 3) After import is complete, click & release on Bookmarks menu. --> "Bookmark this page" mini-dialog appears. (BUG)
Summary: clicking Bookmarks menu when Firefox starts, tries to add current page as bookmark → Clicking Bookmarks menu toggles "Bookmark This Page", when you have lots of bookmarks
(In reply to comment #82) I have the bug on my Firefox 3.0, but your procedure does not activate the bug for me. I have 418 bookmarks. With my old profile, history and bookmarks menus activate the bug. With a new profile and import bookmarks, no bug. Perhaps, not only bookmarks are the cause of the bug. History cache is also the cause ? When these menus are displayed, Firefox searches the icons in bookmarks list and in history cache, this work takes time and power to display.
Hello, I have the same problem. I use Firefox 3.0.5 on a Windows XP SP3 computer. I have a lot of bookmarks that I feel I need. The bug does not always occur. But, it occurs more times than not. When I put it on Safe Mode it works just find. I tried disabling each add on, one by one, to see if it is an add on, and the problem persists. Please, fix this annoying bug. It happens almost every time I start a new session.
I have the same problem, but I also see it in Safe Mode, so it's definitely not plugin related. I have observed the problem since Firefox 3.0, I have not had any issues before. Interestingly, I only have the problem on one of my two machines. Both have a lot of bookmarks yet the bug only happens on one of them. The machine that's fine is a w2000 machine, the one that has the problem is an XP machine. Considering that other platforms (linux) also report the bug, however, I doubt that that the o/s plays a role. Reinstalling Firefox from scratch has not helped, nor has creating additional profiles helped. It's *really* annoying. Is there perhaps a way to completely turn off the "quick bookmark" feature? Many thanks, David.
I recently got my laptop computer back, and had to reinstall Firefox as well as all the extensions and bookmarks. So far, I haven't had the problem.
Hello. This is an update to my Comment #84. I am by no means a computer expert, but in my humble opinion, after testing all of my add-ons individually, I discovered that the problem occured only when I had the "RealPlayer Browser Record Plugin" enabled. So, here's what I suggest in order to reproduce the bug. 1. Download and install the "RealPlayer Browser Record Plugin," probably from the RealPlayer website onto your Firefox 3.0.5. 2. After "RealPlayer Browser Record Plugin" is enabled, (if you had to restart the browser, close the browser window, wait a few seconds, and then) open Firefox 3.0.5. and click "Bookmarks." 3. Close the browser window and repeat step 2 several times to confirm that it is "RealPlayer Browser Record Plugin," that causes the problem. If my theory is correct, then perhaps the best remedy is to uninstall "RealPlayer Browser Record Plugin," and then notify the RealPlayer company or whoever is responsible to fix it.
Unfortunately, I tried toggling the enable/unable option for this add-on and restarting Firefox, but the problem still persists regardless of the state of this add-on. The option to uninstall this add-on was grayed out, so I didn't try uninstalling it.
Plugins (add-ons) are definitively not the cause of this bug : I deactivate ALL the plugins renaming the plugins directory (about:plugins confirms) and then the bug is still here.
(In reply to comment #87) > With the help of Daniel's bookmarks I found finally which bug caused the > problem. It is: bug 279703. > http://bonsai.mozilla.org/cvsquery.cgi?module=PhoenixTinderbox&date=explicit&mindate=2007-07-04+02%3A00&maxdate=2007-07-04+10%3A00 if that's true, this is a really good news, the bad news is that patch is a rewrite, quite big. Thanks for the search Ria!
oh and i really think having a lot of bookmarks is somehow involved, but it's not the cause, i've seen the issue with few bookmarks, and i've not seen it with a lot of them. So having a lot of bookmarks makes the issue more reproducible, but is not the real cause. So morphing title based on ria discovery, i'm not completely surprised that this could be an issue with popups bindings/widgets being lazy.
Summary: Clicking Bookmarks menu toggles "Bookmark This Page", when you have lots of bookmarks → Clicking Bookmarks menu toggles "Bookmark This Page", due to async popup widgets creation
Well, apparently, this bug affects different people with different systems differently. I use Firefox 3.0.5 on a Windows XP SP3 computer. All I know is that immediately that I disabled the "RealPlayer Browser Record Plugin 1.0" extension the problem was resolved. The bug has not re-occurred ever since. This is really strange that everyone here is affected with the same bug in different ways. I guess if it is fixed there would have to be a different fix for each system.
Now that I think about it, I believe I started getting this error after I installed the RealPlayer plugin. I don't have it now, after my HDD failed, and I still have yet to experience a problem.
Well, I disabled the Real Player Plugin add-on and much to my surprise the bug disappeared. Unfortunately for me, it is more annoying to be without the add-on, than to have the bookmark problem. I have simply acquired the habit of holding down the mouse button until the pull down bookmark list appears. I have Windows XP SP3 with Firefox 3.0.5, and RealPlayer 11.0.5 with RealPlayer Browser Record Plugin 1.0. Dan Mulligan
Like others, I can confirm that disabling the Real Player Browser plugin seems to resolve the issue. As previously advised I'm running an XP machine with Firefox 3.0.5. I guess this issue should be referred to Real to fix :-) Andrew
(In reply to comment #97) > Like others, I can confirm that disabling the Real Player Browser plugin seems > to resolve the issue. > [...] > I guess this issue should be referred to Real to fix :-) I don't have any RealPlayer / RP browser plugin installed and never had. The issue occurs here as well sometimes. So, I don't think that RealPlayer causes this issue. Maybe RP is involved in any way but it can't be the only cause.
at the moment further confirmations are not useful, we have to analyze comment 87 findings first, so please stop reporting. This is not due to plugins and not due to bookmarks, unless we know what has regressed with xul popup rewrite we don't need further tests.
The likely patch for this bug is in bug 404314 caused by the popup widget not being created when the accessibility api accesses the menu. RealPlayer may be using the accessibility api to get at something (likely some hack of some sort). Someone with this problem with RealPlayer enabled could confirm if that is the problem by checking if the bookmark's menupopup has a menugenerated attribute set by using the DOM inspector. People who don't have RealPlayer installed may have an accessibility tool enabled. Apparently some newer versions of Ubuntu have one enabled by default.
Depends on: 404314
As a completely seperated observation. I have this bug occuring regularly, but I started an experiment a while ago, and the bug so far _never_ appeared when I access the bookmarks menu with the keyboard shortcut (alt+B) so far. Maybe that helps to find the true origin.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20081219 Minefield/3.2a1pre This bug is fixed for me now. At least I can't reproduce it anymore with a new profile. I'm still experiencing the same issue with the History Submenus extension (going Back instead of opening the History menu after the second click) but this problem may have a different cause.
(In reply to comment #102) > (going Back instead of opening the History menu after the second > click) but this problem may have a different cause. Correction, it doesn't go back but it goes to the first item in the list I see now.
i also can't reproduce this with a recent build containing Neil's patch, i'm going to mark this as fixed, and wait for nightly testers reactions, in case someone will still be able to reproduce, we will reopen this bug. patch: https://bugzilla.mozilla.org/attachment.cgi?id=353441 changeset: http://hg.mozilla.org/mozilla-central/rev/d0f00b7ddf75 Thanks Ria and Neil, you did a great work.
Status: NEW → RESOLVED
Closed: 17 years ago → 16 years ago
Resolution: --- → FIXED
Whiteboard: appear fixed by patch in bug 404314
Whiteboard: appear fixed by patch in bug 404314 → appear fixed by patch in bug 404314, see comment 104
(my comment from #404314) ... i tried it and while it makes the ASSERTION go away it doesnt fix the real issue ... i could still reproduce this when having accessibility enabled.
bug 404314 is not yet closed, so could be a particular case having accessibility enabled. Do you see exactly Bookmarks This Page from Bookmarks menu being selected or a random item?
Yes, it's always "Bookmark This Page". I don't think I have any accessibility modules installed other than what comes default in a Windows XP Tablet laptop. Perhaps there is something though (zooming? tablet interface?) because I don't have the problem on my w2k desktop machine. Best, David.
(In reply to comment #106) > bug 404314 is not yet closed, so could be a particular case having > accessibility enabled. Do you see exactly Bookmarks This Page from Bookmarks > menu being selected or a random item? I see this on all menus that take a bit to create (namely on first click on bookmarks, help, tools, file, ...). It seems to be usually the first item though, but given that we are not sure what happens here it might also appear random for some other variants of this bug. fwiw, i attached a new patch to bug 404314.
There's at least some truth to the observation with the accessibility functions. I see this bug on only one of two machines I'm regularly using and the one with the bug is the one where I've got the Windows task bar magnifier applet running. Fits with my observation that the problem doesn't occur when using keyboard (magnifier window not covering the menu). I'll see whether disabling the taskbar magnifier brings the problem away.
I'm currently using a tablet PC on Windows Vista. Because of the previous few comments, I uninstalled the "Tablet PC optional components" add-on in Windows Vista and after reboot, I could not reproduce this bug. When this feature is turned on again, the bug comes again. So, it must have something to do with the tablet PC feature...
I am seeing this bug on my HP laptop running Vista. I do not see this bug on my XP desktop. Both are running Firefox-3.0.5. Popup is identical to Ctrl-D. Doesn't seem fixed to me unless I haven't done some extra step to clear out odl data or something
Fixed doesn't mean the patch has been released in a Firefox update yet. It just means it's fixed in the working copy of Firefox that is undergoing active coding. This patch may make it into the next Firefox update or, if that's already frozen, the one after that.
(In reply to comment #113) > Doesn't seem fixed to me unless I haven't done some extra step (In reply to comment #114) > Fixed doesn't mean the patch has been released in a Firefox update yet. It > just means it's fixed in the working copy of Firefox that is undergoing active > coding. To be more clear: "Fixed" generally means it's fixed in Mozilla trunk builds, which are available at http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/ Mark -- if you do happen to try a nightly build, definitely feel free to post your results (fixed vs not-fixed) here. (along with the user-agent string in your downloaded nightly's "Help|About" dialog, to verify which nightly version you end up running)
I'd be happy to try out the new build and report back. If I have troubles and need to go back to the production release do I just uninstall and then download the version from the normal channel? Is there any risk to my bookmarks, passwords or anything else I need to be extra careful about?
(In reply to comment #116) > I'd be happy to try out the new build and report back. If I have troubles and > need to go back to the production release do I just uninstall and then download > the version from the normal channel? You can just download the zipped nightly build, unzip it on your desktop, and run the "Firefox.exe" included there, and then delete that folder when you're done. No need to install/uninstall. > Is there any risk to my bookmarks, > passwords or anything else I need to be extra careful about? Nightlies are generally pretty safe, but it's probably a good idea to back up your profile folder first, as described here: http://support.mozilla.com/en-US/kb/Backing+up+your+information
Blocks: 431397
Sorry. I got nowhere running the nightly update (firefox-3.2a1pre.en-US.win32.installer.exe) that I downloaded a few days ago. When I ran it it said it was installing 'Minefield' (not a great name for those of us trying to be careful!) but it installed fine. When I attempted to run it I was greeted with a request to type in my master password. Since the normal version of Firefox doesn't ask for that password until I visit a page that requires password information I simply uninstalled the new version and went back to the old one. Keep in mind that I'm paranoid and I'm thinking things like maybe this is all an elaborate attempt for me to give away private information so it wasn't worth my efforts proceeding. If this is a new bug I'll file it. If it's a bug that's been fixed already I'll get a new download.
NOT FIXED!!! I downloaded the latest nightly about 10 min ago. Clicked bookmarks. Boom. Page Bookmarked! Trunk is Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20081227 Minefield/3.2a1pre Sorry guys. We get to keep looking. I did not however get Mark's bug from comment #118 about having to give the master password. I haven't seen that happen for about 7 months in nightlys.
I can't reproduce this bug any longer. But at the time it was occurring, if mozilla was bookmarking the page when I clicked the bookmarks menu, if I were to simply open the Preferences window, and close it, the bookmarks menu would then work normally, for the rest of the session, I believe.
(In reply to comment #118) > When I attempted to run it > I was greeted with a request to type in my master password. (In reply to comment #119) > I did not however get Mark's bug from comment #118 about having to give the > master password. I haven't seen that happen for about 7 months in nightlys. That's bug 451267, and it indeed _looks_ scary, but is in fact fine. (It's due to a one-time password-database-format upgrade, which is why tssman.jake would've seen it a while back but doesn't see it now.) (In reply to comment #119) > NOT FIXED!!! Me too -- I just re-tested this, and I can still reproduce this bug using today's nightly + fresh profile + my "2000 bookmarks" attachment. After I imported the bookmarks, I hit the bug on each of the first 3 times I clicked the "Bookmarks" menu. (The fourth time, the menu appeared as normal.) I used this nightly: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2a1pre) Gecko/20081227 Minefield/3.2a1pre --> Reopening bug. :-/
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Whiteboard: appear fixed by patch in bug 404314, see comment 104
Version: 3.0 Branch → Trunk
(In reply to comment #121) > (In reply to comment #118) > > When I attempted to run it > > I was greeted with a request to type in my master password. > (In reply to comment #119) > > I did not however get Mark's bug from comment #118 about having to give the > > master password. I haven't seen that happen for about 7 months in nightlys. > > That's bug 451267, and it indeed _looks_ scary, but is in fact fine. (It's due > to a one-time password-database-format upgrade, which is why tssman.jake > would've seen it a while back but doesn't see it now.) > OK, I think this thread has scared me enough that I'm probably better to live with the bug for the time being. I'm worried that if I start letting the nightly update version make changes to my password-database-format then should I want or need to go back to ver. 3.05 I'd be in trouble. Better in the short term that I do nothing, at least in my main Vista account. I am wondering whether I can install the newer version in a test account and tell from there that anything has been fixed? Thanks, Mark
I have Firefox 3.05 on Linux with a lot of bookmarks (450k) and have the same problem. What works for me is clicking on the Bookmarks menu item and holding the button down for about 1 second. The menu drops down as it should. Fast clicking the menu will result in the Page Bookmarked popup every time. Hope this helps. Gary
Just a two quick notes (which my be helpful): On my pretty-fresh LINUX Shiretoko nightly, when it happens: a) once it starts, it continues to do it EVERY TIME until a do a restart-- and then the problem is gone, might be days before it comes back. b) no "RealPlayer' on mine, ever. - - - - - ShireToko Branch definitely gets into thinking that it's somehow within a "bookmark this page" OR a "bookmark this tab" command, sequence, when it absolutely is not. I have don't have any nonstandard accessibility options in place, so I'll SWAG that to be a read herring too. I'll definitely try Gary's workaround (comment #125) the next time it occurs here, and report back on what happens to me. That might be a few days-- my only exposes the problem as a VERY sporadic event.
You guys may want to take a look at Bug 473291 for a method of reliably reproducing a similar issue. But please DO NOT dupe Bug 473291 to this one, as I am hopeful that my methods in Bug 473291 provide a more reliable way of reproducing the issue and should aid identification of the culprit.
Summary: Clicking Bookmarks menu toggles "Bookmark This Page", due to async popup widgets creation → Clicking to open slow menu (e.g. Bookmarks) invokes first item in menu (e.g. "Bookmark This Page"), due to async popup widgets creation
I have seen this a lot on linux with a trunk build, here is what was logged by my debug-build: WARNING: NS_ENSURE_TRUE(controller) failed: file /home/ddahl/code/moz/mozilla-central/mozilla/accessible/src/base/nsCaretAccessible.cpp, line 124 #note: The browser was started and I waited until it was totally done logging on starup, then I clicked the menu and the following was logged: ###!!! ASSERTION: Never ran into the same child that we started from: 'sibling', file /home/ddahl/code/moz/mozilla-central/mozilla/accessible/src/atk/nsAccessibleWrap.cpp, line 980 ###!!! ASSERTION: must have binding parent when in native anonymous subtree with a parent node: '!IsInNativeAnonymousSubtree() || GetBindingParent() || !GetParent()', file ../../../dist/include/content/nsIContent.h, line 217 ###!!! ASSERTION: Never ran into the same child that we started from: 'sibling', file /home/ddahl/code/moz/mozilla-central/mozilla/accessible/src/atk/nsAccessibleWrap.cpp, line 980 ###!!! ASSERTION: Never ran into the same child that we started from: 'sibling', file /home/ddahl/code/moz/mozilla-central/mozilla/accessible/src/atk/nsAccessibleWrap.cpp, line 980 ###!!! ASSERTION: Never ran into the same child that we started from: 'sibling', file /home/ddahl/code/moz/mozilla-central/mozilla/accessible/src/atk/nsAccessibleWrap.cpp, line 980
Hi all, I have the exact same problem all the time, when I click on the 'Bookmarks' menu I get the "add new bookmark" menu box pop-up, only on the first request during a session, if however, I slow down and keep the mouse button depressed & wait a second or so it works properly. I have just updated FF to version 3.06 and it didn't fix this issue.
ive had this problem for ages - months - got the new 3.06 and it just happened again - i click on bookmarks normally when just starting browser so on google - then a box comes up and asks me if i want to book mark google.com - if i ignore it it automatically bookmarks google. hope someone can fix it - it dont happen every time i click bookmarks its quite random so i have no idea why this happens
I can confirm this on Firefox 3.0.6 and Ubuntu 8.10. Its a fresh install so I have only 6 bookmarks and 3 extensions.
For some reason, after having to replace my hard drive twice, and unable to reinstall every bookmark and extension, I have yet to have this problem. I do have close to the same amount of bookmarks and extensions, but the one extension that I didn't have after the first crash was the Real Player. I know that it's not the cause of this problem, but it might have a part.
I have replicated this problem on four different computers in the past week. Two were brand new systems, Windows Vista and XP. None of the Firefox installs had any bookmarks or any kind of extensions at all.
Removing myself from this thread
I enabled javascript.options.showInConsole and javascript.options.strict. After that the click that should open the menu but instead opens the dialog logged this into the error console (three times in a row): > Warning: reference to undefined property menupopup.childNodes[i].folderId > Source file: chrome://browser/content/places/editBookmarkOverlay.js > Line: 667 Maybe this helps tracking this bug down.
Marco says we're hitting http://mxr.mozilla.org/mozilla-central/source/layout/xul/base/src/nsMenuFrame.cpp#494 That means IsMenu() is returning false, which seems wrong. He says this->mIsMenu is zero.
frametree dump: http://www.bonardo.net/mozilla/frametree.txt where 'this' is 0639DA50 thanks to roc for guidance in taking those, since i can sometimes reproduce regularly, i'll continue to be available for testing/debug.
OK, the event is being delivered to the first item of the bookmarks menu. dholbert provided dumps which clearly show an event is being forwarded through the bookmarks popup menu's view/widget. I think that means we must have shown the view in nsMenuPopupFrame::AdjustView. But dholbert and Marco's dumps show the view and frame position are still at (0,0) which seems to mean we didn't do nsMenuPopupFrame::SetPopupPosition from nsMenuFrame::DoLayout, or if we did, it failed for some reason. I can't figure out how we could execute the body of AdjustView before SetPopupPosition changes the popup origin, though. I think we need someone to set a breakpoint on SetPopupPosition and trigger to the bug, to see if that breakpoint gets hit.
We should also check to verify that the call to SetViewVisibility in nsMenuPopupFrame::AdjustView is hit.
(In reply to comment #145) > dholbert provided dumps which clearly show an event is being forwarded [...] These dumps are available at http://people.mozilla.org/~dholbert/tests/406646/frametree_with_events.txt if anyone's interested. (I can't post them here because they're 1.8MB each.) The dumps are taken after hitting a breakpoint at nsMenuFrame.cpp:494, & they were made using the STR in comment 82.
Elaborating on comment #145, what I *suspect* is happening is that mouse-down has triggered opening of the popup, and AdjustView has made the popup view visible (although it's not actually drawn yet) so it can receive events, but then the mouse-up event arrives before SetPopupPosition is called (or maybe SetPopupPosition is called, but it hasn't done anything yet). That would explain why once the menu is opened once, the bug won't happen again in that window; after the menu is opened, the popup has the right position and the next time it opens it won't be at (0,0) at any time. This could also very well be the cause of bug 404314. If the same thing can happen with the context menu, then effectively the mouse-up would be processed with the popup at its old position, which could either mean nothing happens or an item at a seemingly random position is activated.
(In reply to comment #145) > I can't figure out how we could execute the body of AdjustView before > SetPopupPosition changes the popup origin, though. I think we need someone to > set a breakpoint on SetPopupPosition and trigger to the bug, to see if that > breakpoint gets hit. Actually, someone who can reproduce should add printf logging to SetPopupPosition and AdjustView to see if they get called and what path they take, and then rerun with the breakpoint at Execute(aEvent). What gets printed just before we hit the breakpoint would be very interesting...
(In reply to comment #149) > Actually, someone who can reproduce should add printf logging to > SetPopupPosition and AdjustView to see if they get called I'm assuming you're referring to those as methods of nsMenuPopupFrame. I placed breakpoints (and added printf's) in both those methods, but it turns out that neither of them gets called during the time from when I click the Bookmarks menu to when I hit the Execute(aEvent) line at nsMenuFrame.cpp:494 It goes something like this: - I click Bookmarks menu. Then, in GDB: - I hit breakpoint at nsMenuFrame.cpp:494, at Execute(aEvent) - I hit breakpoint at nsMenuPopupFrame::AdjustView - I hit breakpoint at nsMenuPopupFrame::AdjustView again - I hit breakpoint at nsMenuPopupFrame::SetPopupPosition - (I hit AdjustView & SetPopupPosition a few more times, though I think these ones may be for the buggy "Page Bookmarked" popup, the symptom of this bug)
Hi all, unfortunately I cannot comment on the technical detail of how and why the bug occurs, but I may contribute to making it easier to reproduce and understand: I see that on 2 machines I use, I can toggle this bug on and off: - The bug _always_ appears on both machines for the first click into the bookmarks menu, when I use the taskbar magnifier tool (http://www.microsoft.com/windowsxp/Downloads/powertoys/Xppowertoys.mspx). - The bug _never_ appears when I don't have the magnifier toy in the taskbar. Additionally, - The bug _never_ appears when I use keyboard shortcuts (Alt, b or Alt+b) to access the bookmarks menu (regardless whether taskbar magnifier is on or off) good hunting!
sometimes i see Execute is run (in DoLayout) just after mPopupFrame->Layout(aState); and just before mPopupFrame->AdjustView(); but i also see cases where execute is called before any DoLayout call. i can also tell mousedown fires on the correct menu inj the menubar, while mouseup fires on the menuitem. but coordinates for the 2 events are the same.
OK, so set a breakpoint in nsView::SetVisibility where it calls mWindow->Show(PR_TRUE) and get a stack trace; if you can get a stack trace for a click that eventually hits the bad Execute, that stack should show how our window is being made visible prematurely.
doesn't break there for me.
OK I think I finally understand what's happening here. 1) The mouse-down event fires, which triggers nsXULPopupManager::ShowMenu on the bookmarks popup menu. 2) That triggers nsXULPopupManager::ShowPopupCallback which queues an asynchronous nsXULPopupManager::FirePopupShowingEvent 3) nsXULPopupManager::FirePopupShowingEvent calls nsXULPopupManager::ShowPopupCallback which adds the popup to nsXULPopupManager::mPopups. 4) Now the mouse-up event arrives before the popup's position has been set; nsMenuPopupFrame::SetPopupPosition has not been called by nsMenuFrame::DoLayout. I'm not sure how opening a popup triggers nsMenuFrame::DoLayout, but it's definitely asynchronous and that allows the mouse-up to slip in before the DoLayout. 5) The mouse-up is targeted at the root widget, that's good. The event is passed down to the PresShell. 6) PresShell::HandleEvent has code to search all open popups to see if they should be handling this mouse event. It calls nsXULPopupManager::GetOpenPopups to do that, which returns popups that are open but invisible. 7) It finds our open-but-invisible popup and dispatches the event to it. The fix should be to exclude the open but invisible popups from PresShell::HandleEvent's search. There are various ways to do that, it should be easy.
Attached patch fix — — Splinter Review
This should do it, just change GetOpenPopups to GetVisiblePopups. The caret code only cares about visible popups too.
Assignee: nobody → roc
(In reply to comment #157) > Created an attachment (id=363209) [details] > fix Yay -- so far, this patch does indeed seem to fix it for me, using the attachment & steps from comment 82! I'm going to test it a bit further, and then I'll revert the patch to make sure that re-breaks this bug, just to be sure.
Comment on attachment 363209 [details] [diff] [review] fix OK, let's go for review.
Attachment #363209 - Flags: review?(enndeakin)
(In reply to comment #158) > I'm going to test it a bit further, and then I'll revert the patch to make sure > that re-breaks this bug, just to be sure. Just to follow up on this -- after some more testing, the patch still seems good. I consistently get correct behavior with a patched build, and then when I revert the patch, I start getting the buggy behavior again.
First test was successful, using the method i commonly used to reproduce this bug, does not show it anymore. But i'll do some additional test tomorrow. Looks good so far!
For others interested in testing this patch (particularly to see if it fixes bug 404314), I've made two try-server builds with this patch: Based off of mozilla-central trunk (Firefox 3.2 pre): https://build.mozilla.org/tryserver-builds/2009-02-19_16:11-dholbert@mozilla.com-try-f7d80ef59ea/ Based off of mozilla-1.9.1 branch (Firefox 3.1 pre): https://build.mozilla.org/tryserver-builds/2009-02-19_18:04-dholbert@mozilla.com-try-72cf37a71ea/
second test went fine, i'm still unable to reproduce, due to the intermittent nature of the bug it's hard to tell for sure, but the issue looks gone as far as i can test for it. Thanks Robert!
Summary: Clicking to open slow menu (e.g. Bookmarks) invokes first item in menu (e.g. "Bookmark This Page"), due to async popup widgets creation → Clicking to open slow menu (e.g. Bookmarks) invokes first item in menu (e.g. "Bookmark This Page")
I know it's been a long time since I filed this bug, but since I saw the recent activity on the bug, I thought I should comment. I have installed the try-server build (thanks so much Daniel), I have done some testing with that build. I have added the additional bookmarks that are attached to the bug to build up a larger bookmark group, which makes it easier to reproduce. With the try-server build, I'm still able to reproduce the bug. Just to make sure that this is indeed your try-server build: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2a1pre) Gecko/20090219 Minefield/3.2a1pre ID:20090219164851 Things to note, when testing for this bug, my homepage is netvibes.com which is an ajax heavy site. While the site is still loading (firefox under startup stress) I click on 'Bookmarks', firefox then attempts to bookmark the page thats loading. I also found that with this build, when I let the site fully load and firefox load, the bug does not occur. If I launch firefox, then stop the page load, then click 'Bookmarks' which firefox is still 'starting up' I can reproduce the bug. It seems that this bug is much easier to reproduce when firefox is doing its cold start activities. I'm not sure how that will help narrow it down, but I have more time to test and help kill this bug.
Attachment #363209 - Flags: review?(enndeakin) → review+
Whiteboard: [needs landing]
Pushed http://hg.mozilla.org/mozilla-central/rev/708a4e3818d3
Status: REOPENED → RESOLVED
Closed: 16 years ago → 16 years ago
Resolution: --- → FIXED
Whiteboard: [needs landing] → [needs 191 approval]
Comment on attachment 363209 [details] [diff] [review] fix Fixes a pernicious bug affecting a lot of people
Attachment #363209 - Flags: approval1.9.1?
Eric (and others), I've closed this bug because the patch fixes a problem that a lot of people have which matched the original description; most of the comments in this bug are *probably* about the issue that was fixed. If you still have a bug in nightly builds after tomorrow, please file a new bug.
Requesting "wanted1.9.0.x" -- this bug has annoyed tons of Firefox 3.0.x users, so it would be great to fix this on that branch.
Flags: wanted1.9.0.x?
Flags: in-testsuite+
Flags: in-litmus?
verified FIXED on build: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3) Gecko/20090305 Firefox/3.1b3 ID:20090305133223 Test case https://litmus.mozilla.org/show_test.cgi?id=5954 was updated to reflect regression testing.
Status: RESOLVED → VERIFIED
Flags: in-litmus? → in-litmus+
Blocks: 404314
No longer depends on: 404314
Flags: wanted-firefox3.1?
Component: Places → Menus
QA Contact: places → menus
Target Milestone: --- → Firefox 3.2a1
Realistically, this should probably block given the number of times this has been reported and seen in the wild.
Flags: blocking-firefox3.1?
Blocking, no longer needs approval.
Flags: blocking-firefox3.1? → blocking-firefox3.1+
Priority: -- → P2
Whiteboard: [needs 191 approval]
Component: Menus → Layout
Flags: wanted-firefox3.1?
Flags: blocking-firefox3.1+
Product: Firefox → Core
QA Contact: menus → layout
Target Milestone: Firefox 3.2a1 → ---
Flags: blocking1.9.1?
Target Milestone: --- → mozilla1.9.2a1
Flags: blocking1.9.1? → blocking1.9.1+
Component: Layout → XP Toolkit/Widgets: Menus
QA Contact: layout → xptoolkit.menus
Whiteboard: [needs 191 landing]
Here's the fix backported to 1.9.1. There were just two trivial bitrot-ish contextual differences in 1.9.1 vs. mozilla-central -- one change is in a comment, and the other is a simple variable renaming (from Bug 396699) -- s/mCurrentMenu/mPopups/ -- in contextual code within "nsXULPopupManager::GetOpenPopups". (which is now named GetVisiblePopups after this patch)
Keywords: fixed1.9.1
Whiteboard: [needs 191 landing]
The 1.9.1 patch applies with fuzz 6 to current 1.9.0.x branch -- the fuzz is just needed because of an "#ifdef MOZ_XUL" that's been added to nsCaret::IsMenuPopupHidingCaret() in 1.9.1 (but wasn't present in 1.9.0.x). Here's a clean 1.9.0.x patch. (Doesn't need any fuzz to apply.) Requesting approval to land this in the 1.9.0.9 timeframe, as it fixes a significant issue that's been majorly annoying many users since the initial 3.0 release.
Attachment #367667 - Flags: approval1.9.0.9?
I have it on Vista, XP, Ubuntu, Opensuse on my Bokmarks, History and File menues on firefox 3.0.7. I am newbie so i don't understand how come it is "verified fixed" when it is still here? Hm.. Will it be fixed in Firefox 3.5? TNX
(In reply to comment #183) > I have it on Vista, XP, Ubuntu, Opensuse on my Bokmarks, History and File > menues on firefox 3.0.7. I am newbie so i don't understand how come it is > "verified fixed" when it is still here? Hm.. Will it be fixed in Firefox 3.5? > TNX This will be fixed for 3.5, and maybe 3.0.9 if the patch gets approval.
why has this bug been marked as fixed?? when the problem is still there with version 3.0.8??
Because this bug has been fixed on trunk (status=FIXED), and also landed on the 1.9.1 branch for Firefox 3.5 (keyword=fixed1.9.1)... As you can see from the flags, it is wanted for the 3.0 branch (wanted1.9.0.x=?) but a driver has not yet agreed to this request. If it get approved for the 1.9.0 Firefox 3.0 branch it will get an appropriate keyword when it had landed.
You are talking about the 3.0 and the 3.5 branch, what about the 3.1 branch? The bug is present in this branch aswell and I think it should get fixed there.
3.1 is being renamed to 3.5 with the next beta release. They're one and the same.
Blocks: 454693
No longer depends on: 454693
Comment on attachment 367667 [details] [diff] [review] fix, backported to 1.9.0.x Approved for 1.9.0.10, a=dveditz for release-drivers
Attachment #367667 - Flags: approval1.9.0.10? → approval1.9.0.10+
I landed attachment 367667 [details] [diff] [review] on 1.9.0.x branch: Checking in layout/base/nsCaret.cpp; /cvsroot/mozilla/layout/base/nsCaret.cpp,v <-- nsCaret.cpp new revision: 1.195; previous revision: 1.194 done Checking in layout/base/nsPresShell.cpp; /cvsroot/mozilla/layout/base/nsPresShell.cpp,v <-- nsPresShell.cpp new revision: 3.1125; previous revision: 3.1124 done Checking in layout/xul/base/public/nsXULPopupManager.h; /cvsroot/mozilla/layout/xul/base/public/nsXULPopupManager.h,v <-- nsXULPopupManager.h new revision: 1.31; previous revision: 1.30 done Checking in layout/xul/base/src/nsXULPopupManager.cpp; /cvsroot/mozilla/layout/xul/base/src/nsXULPopupManager.cpp,v <-- nsXULPopupManager.cpp new revision: 1.61; previous revision: 1.60 done
Keywords: fixed1.9.0.10
I have uninstalled 3.0.10. Went back to 2.0.0 and had no troubles. The updater had me go to 3.0.5 and the bookmarking bug is still evident! Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.5) Gecko/2008120122 Firefox/3.0.5 Windows XP Professional sp 2 with Zone Labs Zone Alarm Security Suite I cannot delete or even change any of my bookmarks! This is not only irritating but time consuming! THIS IS NOT FIXED! Nothing has changed since 3.0.0 was released. The ease of use that Firefox exhibited before 3.0.0 is gone.
Install the beta version of 3.6a1pre. The bookmark issue is no longer an issue.
(In reply to comment #196) > I have uninstalled 3.0.10. Went back to 2.0.0 and had no troubles. The > updater had me go to 3.0.5 and the bookmarking bug is still evident! it is really time consuming since you are testing it on a build that does not had the patch. keyword says "fixed1.9.0.11" which means firefox 3.0.11 will had this fix.
I still have this bug in 3.0.10 is it ever going to be fixed???
Flags: blocking1.9.0.11?
*** THIS IS ALREADY FIXED IN 3.0.11. ***
Flags: wanted1.9.0.x?
Flags: blocking1.9.0.11?
(In reply to comment #201) > THIS IS ALREADY FIXED IN 3.0.11. This bug will be fixed for Firefox 3.0.11 which will be released beginning of June. For details see https://wiki.mozilla.org/Releases/Firefox_3.0.11.
Whiteboard: [see comment 202 before commenting]
Verified for 1.9.0.11. This is fixed for that release in the pre builds.
Keywords: fixed1.9.0.11 → verified1.9.0.11
Keywords: common-issue+ → common-issue-
Component: XP Toolkit/Widgets: Menus → XUL
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: