>>> My Info: Win7_64, Nightly 46, 32bit, ID 20160121030208 > screencast: https://dl.dropboxusercontent.com/s/ddtunxl4p1qmvtd/screencast%201%20-%20The%20back-button%20popup%20menu%20displays%20incorrect%20item%20from%20tab%20history%20as%20selected.webm?dl=0 STR: 1. Open new tab, type "data:,a" (without quotes) in location bar, press Enter 2. Select all text in urlbar, type "data:,b" (without quotes), press Enter 3. Click on the Back button, then immediately right-click the Back button: 3.1. Hover mouse over the Back button (don't move mouse until Step 4) 3.2. Hold left mouse button 3.3. Release left mouse button 3.4. Hold right mouse button 3.5. Release right mouse button [Perform Step 3 as fast as possible. See Notes (1) ] 4. Click on the page content to hide the popup menu 5. Repeat Steps 3-4 several times Result: See screencast. Wrong item in tab history is displayed as selected with "radio" icon, and another one is displayed as selected with bold font. Expectations: Only 1 item should be displayed as selected: that item should have bold text and "radio" icon This was caused by bug 1148505. Regression range: > https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=93052c1a0e482d0043834855e8bc9240cf411650&tochange=fba67babe664eeb189d2795e36e9edc2cae94f9d Notes: 1) Steps 3.1-3.5 must be performed as fast as possible, less than 0.5s. That's required because I don't know how a person reading this usually performs such steps. I can reproduce the bug even if I perform Steps 3.1-3.5 in 1 second, but that isn't reliable]
Please try reproducing this issue on the latest nightly release 47.0a1. I can not reproduce this issue as the radio button and the bolded text are on the current url. Name Firefox Version 47.0a1 Build ID 20160201030241 User Agent Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:47.0) Gecko/20100101 Firefox/47.0
(In reply to Justin - QA from comment #1) >>> My Info: Win7_64, Nightly 46, 32bit, ID 20160201030241 I successfully reproduced on 2 Win7 machines. If you provide a screencast, I will try to determine what are you doing wrong. Or, probably, it would be easier to write a script in browser context that will click and right-click those buttons at appropriate speed... I currently don't have time for that.
Status: UNCONFIRMED → NEW
Ever confirmed: true
I think I'm able to duplicate this on Nighty. A fast left-click on the back button followed by a fast right-click to get the context menu off the back button will win open the current history context menu before the page reloads. It's a pretty edgy edgecase, but it smells like something that shouldn't be hard to fix. Autoclose open menu when the page refreshes?
(In reply to Mike Hoye [:mhoye] from comment #3) > fast left-click on the back button followed by a fast right-click to get the context menu > It's a pretty edgy edgecase Make sure you read the whole comment 0, especially that part about "1 second" Obviously I detected this bug when I clicked at a normal speed, ~1s. Here's the video > screencast https://dl.dropboxusercontent.com/s/9nfcn8k8yzbghck/bug%201243011%20comment%204.webm
Neil told me he'd take a look at this case.
Created attachment 8740434 [details] [diff] [review] Don't reopen menu for contextmenu The context menu doesn't have a meaningful parent, so the open property is undefined causing us to always return early.
Assignee: nobody → enndeakin
Status: NEW → ASSIGNED
Attachment #8740434 - Flags: review?(felipc)
Attachment #8740434 - Flags: review?(felipc) → review+
https://hg.mozilla.org/integration/mozilla-inbound/rev/9424f63828ebaf3563cad850ce1cc5f865231f70 Bug 1243011, skip popup open check for back button context menu so that it doesn't sometimes contain the wrong items, r=felipe
Status: ASSIGNED → RESOLVED
Last Resolved: 2 years ago
status-firefox48: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla48
Regression from 43, fairly minor edge case, and it's late to uplift this to 47 beta. Wontfix for 47, fixed in 48.
status-firefox47: affected → wontfix
This isn't fixed. There was no change in behavior. ???
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
This appears to be fixed for me. Can you specify just the specific steps that fail or perhaps post a video of this?
Created attachment 8757712 [details] bug 1243011 comment 12.webm The steps are the same. On the screencast I only added some logging to make this more obvious.
Affected builds: "first good" after comment 8 - 9424f63828ebaf3563cad850ce1cc5f865231f70 (mozilla-inbound) "last bad" before comment 8 - ac43dab284afd189ed2b0f4c1906a45e0c1736dd (mozilla-inbound) Beta 48.0b1 ID 20160606200529 Aurora 49.0a2 ID 20160620183010 Nightly 50.0a1 ID 20160620030215
status-firefox48: fixed → affected
status-firefox49: --- → affected
status-firefox50: --- → affected
status-firefox48: affected → wontfix
status-firefox49: affected → fix-optional
status-firefox50: affected → fix-optional
You need to log in before you can comment on or make changes to this bug.