fixed1.8.1, regression, verified22.214.171.124
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20050828 Firefox/1.6a1 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20050828 Firefox/1.6a1 menu highlight in bookmarks menu is blinking rapidly and not responsive to movement of cursor on the bookmarks submenus. Reproducible: Sometimes Steps to Reproduce: 1.open bookmars menu 2. 3. Actual Results: blinking menu highlight and unresponsive menu navigation Expected Results: steady hightlight of current menu item and responsive menu navigation.
I see this too sometimes. When I move my mouse over the contents of the main Bookmarks menu the selections start flickering. The statusbar urls flicker in the same rhythm. Bookmarks folders don't expand, except for the Bookmarks Toolbar Folder and its subfolders. Links work normally. I see it also in the Go menu, but never two menus at the same time. It happens in trunk and in branch. I haven't found out yet if it has something to do with an extension. I'll try disabling the ones I installed in the last few weeks.
I saw this once after I changed a theme on windows2000. Happened with the Bookmarks menu and the Go menu. Not with any other menu.
Ok, I think I have a reproducable way to experience the bug: - Open Gmail (you've to have a gmail account and be logged in). - Minimise the browser. - Wait for a while (1 minute or so). Probably some kind of frame loading needs to happen. - Change you os theme with the windows theme manager. After the theme change, the browser comes automatically up (bug 307117 or earlier) In the Gmail tab, the issue doesn't happen. - Open a new tab. - Now hover over the bookmark menu-items, you get to see the bug. Another aspect of the bug: The bug only happens over the bookmark menu-items that are over the content area. This could be a windows widget issue, I guess.
Created attachment 194934 [details] gmail replacer This can act as a replacement for Gmail. The rest of the steps need to be carried out in the same wayl
Well, I have been able to reproduce it in 2005-08-26 build, but not in 2005-08-25 build. http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2005-08-25+07%3A00%3A00&maxdate=2005-08-26+08%3A00%3A00&cvsroot=%2Fcvsroot But I haven't been able to consistently reproduce it, so this regression range might be bogus.
Assignee: nobody → roc
Status: UNCONFIRMED → NEW
Component: Bookmarks → Layout: View Rendering
Ever confirmed: true
Product: Firefox → Core
QA Contact: bookmarks → ian
Version: unspecified → Trunk
*** Bug 301561 has been marked as a duplicate of this bug. ***
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20050909 Firefox/1.6a1 ID:2005090916 Seeing this on Linux (Fedora Core 4 with GNOME), too.
OS: Windows XP → All
Hmm, this is probably an older bug. The duped bug indicates rv:1.8b3) Gecko/20050712 as user agent.
*** Bug 309032 has been marked as a duplicate of this bug. ***
Summary: menu highlight in Bookmaks menu is blinking rapidly → menu highlight in Bookmarks menu is blinking rapidly
*** Bug 307709 has been marked as a duplicate of this bug. ***
See bug 311227, which has a link to a Flash movie that I believe illustrates the same issue as this bug.
*** Bug 311227 has been marked as a duplicate of this bug. ***
Severity: normal → major
Whiteboard: URL shows issue (flash movie)
drivers: This is a highly visible bug, making bookmark folders and advanced features of Seamonkey available from the menus essentially unusable. Note that unfortunately it does not have any good steps for reproduction or testcases yet, but it does happen with every browser session I have. Nominating blocking1.8rc1.
Summary: menu highlight in Bookmarks menu is blinking rapidly → Certain submenues blink rapidly when highlighted
I can only reproduce this issue when the computer comes back from sleep mode (xp)
*** Bug 311490 has been marked as a duplicate of this bug. ***
Summary: Certain submenues blink rapidly when highlighted → Certain submenus blink (flash, flicker) rapidly and do not expand when highlighted (hovered over)
We'd need better steps to reproduce. Not a stop ship bug this late in the game, if this was on the radar earlier, it may have been something we would have tried to address.
Flags: blocking1.8rc1? → blocking1.8rc1-
I also see this after using remote desktop (windows terminal services) into the system to use firefox 1.5 B1 and B2. I do not see this behavior in 1.07.
I have seen this also in Firefox 1.5b1 and 1.5b2. I seem to get it every time (in the bookmarks). I'm using Firefox 1.5b2 with Gnome on Unbuntu Linux.
*** Bug 314188 has been marked as a duplicate of this bug. ***
I could reproduce it with the testcase of comment #3, but only 3 times. Then it stopped. I have never changed XP themes before so it might not depend on themes. The few times it happened to me I had the browser open for a longer time (more than an hour). Because of scrolling problems (scrolling becomes laggy after some time) I have to restart the browser frequently and this might be the cause that I don't see this bug anymore.
Oh well, when I have two browsers open (branch and trunk) and one with Gmail and I change themes, the bug does not happen in the browser with Gmail but in the other one! :D
I observed the same, and that sub menus are highlighted when pointer is moving over them, but not when it is still - producing a flickering effect. Hovering does not open submenu, but clicking does.
I see the same behavior as comment #22 with 1.5-RC1 using the default Firefox theme (on Fedora Core 4).
Appears to fixed for me in 1.5rc2..
Spoke too soon :| It's a tough one - sometimes comes on straight away, sometimes after several hours use. I note now that all the icons for the bookmark folders are now permanently stuck in the open mode. An hour ago, before the flickering came back, they switched from closed to opened folders as the mouse passed over them.
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8) Gecko/20051110 Firefox/1.5 Linux RC 2 observed.
(In reply to comment #26) > Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8) Gecko/20051110 Firefox/1.5 > > Linux RC 2 observed. > I observed the same problem on Windows Server 2003. It does not occurred immediately but only after some delay. Moreover, the problem exists only when there is more than one tab and it does not appear on the most left tab. Same configuration (RC2 + extensions) is OK on Windows XP Pro SP1.
When I've seen this bug, it's always been right after I did something with tabs, such as after opening a new blank tab. Definitely doesn't have anything to do with changing themes in Windows for me.
*** Bug 317082 has been marked as a duplicate of this bug. ***
I get this on 1.5 RC3 of firefox on ubuntu linux. makes the browser unusable for me since I heavily use bookmarks, I guess have to use 1.0.7 till this bug is fixed.
(In reply to comment #30) > I get this on 1.5 RC3 of firefox on ubuntu linux. > makes the browser unusable for me since I heavily use bookmarks, I guess have > to use 1.0.7 till this bug is fixed. I see it also on Ubuntu, but even if it's flashing, you can still 'manually' click to open submenus.
I have had the same problem too in rc1, rc2 and rc3 (haven't used the betas). os: arch linux firefox: rc3 from mozilla.org
I encounter the bug using Firefox 1.5 RC 3 on Debian with bleeding edge Debian packages. I confirm the workaround mentioned in Comment #31
I think this could be mouse event synthesis not dealing well with floating views --- view display lists for event handling won't include floating views if the event wasn't dispatched from a floating view (unless the mouse is being captured).
Created attachment 204333 [details] [diff] [review] fix This fixes it for me *in my frame display list branch* which reproduces the bug 100% of the time. Martijn, could you test this on a regular build?
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20051123 Firefox/1.6a1 This patch fixes it for me on Linux. I guess Martijn can verify that it works on Windows.
Hi how do i use this patch on 1.5 branch? it fails to patch : patching file view/src/nsViewManager.cppHunk #1 FAILED at 2827. 1 out of 1 hunk FAILED -- saving rejects to file view/src/nsViewManager.cpp.rej
(In reply to comment #35) > This fixes it for me *in my frame display list branch* which reproduces the bug > 100% of the time. Martijn, could you test this on a regular build? I think I still see the issue with the patch (I only need to rebuild view/ , right?)
you need to relink layout ("make libs" in layout/build/)
(In reply to comment #39) > you need to relink layout ("make libs" in layout/build/) Oops, I keep forgetting that. Anyway, after I've rebuilt that, it seems to be fixed, indeed.
When will this fix be included in a release?
Just to be sure, I still have this problem in the ff 1.5 release. The rules I found are: -It never seems to appear in the first tab (only in second or higher tabs) -The flickering only appears on menu items that are above the navigation area. Was the patch included in 1.5? Thanks
No. The fix will most likely be included in Firefox 2.0, and *might* be included in a 1.5 point-release, if there ever is one.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5 - Build ID: 2005111116 I was able to reproduce this, but only once, by: 1. Minimize Firefox. 2. Open Display Properties window and change Windows theme. Firefox is unminimized automatically. 3. Hover items in bookmarks menu. The bookmarks flicker but the folders do not, and open normally. Items in subfolders also flicker. I have also had this happen to links; the cursor would rapidly switch between the hand and arrow icon when hovering a link.
I just want to make this clear. There is a patch for this bug. Martijn and I have tested it on Windows and Linux, and it does indeed fix the problem. Now, this patch is still pending a review, and branch and trunk check-in. That stated, I don't see any reason to post any new comments here saying how to reproduce the issue, or that you're still seeing the issue.
Whiteboard: URL shows issue (flash movie) → [please see comment 46 before commenting]
*** Bug 318936 has been marked as a duplicate of this bug. ***
Hi, how will I be able to resolve this issue? Its annoying as hell when it happens! Will it be part of an update, or will I need to download a patch etc? Thanks, Ben.
I'm not sure this is related, but I suspect it is - so I won't create a new bug yet: Sometimes, right-clicking to save an image, the dialog appears, but when the mouse moves, it disappears and re-appears elsewhere (no buttons pressed). Most of the time, it appears above the cursor, then reappears below the cursor. this seems to be multiple event issue somewhat similar to the above. Anyone notice this? John
I rather doubt that's related...
Now here's an interesting item: I downloaded the source code, thinking about applying the patch. Compiled it first (no patch), Started the program, and I cannot get the flickering to occur... Both binary and self-compiled versions claim same date 20051111. Looked through the code where the patch should go, but it doesn't see to be there. Has this be corrected somewhere else? John
I experience this problem very frequently on Ubuntu amd64 with a Firefox 1.5 that I compiled (and on the 32 bit official 1.5 build I had for awhile). I attempted to apply the patch but the patch command gave an error similar to comment 37. I then applied the patch by hand and recompiled with no errors. The bug is still present for me though on my new build with the patch. In fact, it is even more prevalent in that it now does it 100% of the time instead of randomly. Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8) Gecko/20051212 Firefox/1.5
*** Bug 320113 has been marked as a duplicate of this bug. ***
(In reply to Comment #52 From Steven.S 2005-12-12 16:40 PST) > In fact, it is even more prevalent in that it now does it 100% of the time instead of randomly. I also applied the patch manually and built my own binary from the FIREFOX_1_5_RELEASE branch in CVS. At first, I also had the flicker 100% of the time. Then I was looking at the original nsViewManager.cpp and I think it referred to event.point rather than event.refPoint, so I changed it to "event.point = mMouseLocation - offset" and that fixed the flickering menus for me. Not sure if that is the correct fix, but I've been enjoying my flicker-free Firefox for the past week or two.
Comment on attachment 204333 [details] [diff] [review] fix >+ * views aren't necessarily included in their parent's bounds, so this could >+ * traverse the entire view hierarchy --- use carefully. s/could/will usually/, since most points aren't in floating views You could in theory optimize the IsViewVisible call, but I really don't think it's worth it; it would introduce significant complexity for little value. r+sr=dbaron. Sorry for the delay.
(In reply to Comment #54 From Brad Jackson 2005-12-13 20:22 PST) I made the changes Brad suggested and now the menus do not flicker on my build. Patch needs to be updated before it is checked in.
This is a trunk patch, the refPoint stuff was added with bug 296036. So the patch will work correctly on trunk. Bugs like this one need first to be fixed on trunk, before getting considered getting fixed on branch.
Status: NEW → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → FIXED
*** Bug 320576 has been marked as a duplicate of this bug. ***
*** Bug 320824 has been marked as a duplicate of this bug. ***
Firefox 1.5 has shipped with this problem. Is there plan to checkin 1.8 branch?
13 years ago
Attachment #204333 - Flags: approval1.8.1?
I am just installed update 126.96.36.199 on my computer (Windows 2003 Server, Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:188.8.131.52) Gecko/20060111 Firefox/184.108.40.206) and I note the bug is not yet fixed !
IF this bug were shipped on the 1.8.0 branch, there would be a keyword saying so. This bug is fixed on TRUNK. That's what "fixed" means. Note the approval request for the patch (for the 1.8.1 branch Firefox 2 will be based off of).
*** Bug 325124 has been marked as a duplicate of this bug. ***
*** Bug 323484 has been marked as a duplicate of this bug. ***
Attachment #204333 - Flags: approval1.8.1? → branch-1.8.1?(dbaron)
*** Bug 325971 has been marked as a duplicate of this bug. ***
Comment on attachment 204333 [details] [diff] [review] fix branch-1.8.1=dbaron, but be careful merging it to the MOZILLA_1_8_BRANCH if the patch is from after the event coordinate changes
Attachment #204333 - Flags: branch-1.8.1?(dbaron) → branch-1.8.1+
checked into branch. The event coordinate changes were not an issue, I just had to change refPoint to point. In the old code, event.point starts as pixels relative to the widget origin, and then gets copied to .refPoint and itself morphs into twips relative to view, in nsViewManager::HandleEvent. So at this point in the old code, .point meant what .refPoint always means now.
13 years ago
(In reply to comment #44) > No. > > The fix will most likely be included in Firefox 2.0, and *might* be included in > a 1.5 point-release, if there ever is one. > Sorry for the spam, but is there any way this can get shipped in 220.127.116.11 assuming there is one? This bug is highly visible, occurs on every platform as far as I can tell, and is downright infuriating. Even restarting the browser isn't much help when the problem recurs in a few minutes time.
(In reply to comment #69) > (In reply to comment #44) > > No. > > > > The fix will most likely be included in Firefox 2.0, and *might* be > > included in a 1.5 point-release, if there ever is one. > > Sorry for the spam, but is there any way this can get shipped in 18.104.22.168 > assuming there is one? This bug is highly visible, occurs on every platform > as far as I can tell, and is downright infuriating. Even restarting the > browser isn't much help when the problem recurs in a few minutes time. I concur. I decided not to upgrade our (albeit small) organization to Firefox 1.5 after running into this bug. The user reaction will be "it's broken", even if everything else works great.
Comment on attachment 204333 [details] [diff] [review] fix Let's see what the branch drivers say. I agree that this is a serious polish issue. The risk is not zero but the fix has been on trunk for two months with no reported regressions.
Attachment #204333 - Flags: approval22.214.171.124?
Comment on attachment 204333 [details] [diff] [review] fix approved for 1.8.0 branch, a=dveditz for drivers
Attachment #204333 - Flags: approval126.96.36.199? → approval188.8.131.52+
checked in on branch.
Could someone who has verified this fix on the trunk please pick up the latest 1.5 nightly and verify the fix on the branch? Please adda comment here with your findings.
Status: RESOLVED → VERIFIED
Whiteboard: [please see comment 46 before commenting] → [please see comment 46 before commenting][rft-dl]
I have not seen that problem for some time now. Currently I am using version 184.108.40.206 on Debian.
v.fixed on 1.8.0 branch with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:220.127.116.11) Gecko/20060306 Firefox/18.104.22.168, no flickering in bookmarks with steps from comment #3 (and gmail replacer attachment). If others are seeing this problem with 22.214.171.124, please retest with the latest 1.8.0 branch builds and let us know if things work better for you. Thanks.
Keywords: fixed126.96.36.199 → verified188.8.131.52
*** Bug 331605 has been marked as a duplicate of this bug. ***
Component: Layout: View Rendering → Layout: Web Painting
Product: Core → Core
You need to log in before you can comment on or make changes to this bug.