Closed Bug 791154 Opened 13 years ago Closed 13 years ago

OS X contextual menu goes flying on external monitors

Categories

(Core :: General, defect)

Product:
Core
Component:
General
Version:
17 Branch
Platform:
x86
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED DUPLICATE of bug 788189

People

(Reporter: eric, Unassigned)

Details

(Keywords: regression)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/17.0 Firefox/17.0 Build ID: 20120913042009 Steps to reproduce: 1. Right-click on document body or other non-link element in a browser window on an external monitor. 2. Right-click on link (described result observed). 3. Right-click on a non-link element (described result observed). 4. Right-click on a non-link element. Actual results: Problem: the contextual menu comes up and then moves downward and to the right at what appears to be a 45-degree angle until the bottom of the contextual menu reaches the bottom of the screen (NOT the browser chrome OR viewport, the monitor display area). Then it jumps up directly upward (probably actually one pixel to the right) to its starting vertical offset and continues its down-right slide. Once the menu’s right edge reaches the right edge of the monitor, it slides straight down until reaching the bottom right corner of the monitor. It then jumps back up to its starting vertical offset and slides down to the corner. Repeat ad nauseum. If you need a screencast, let me know. PLEASE NOTE: the monitor on which this happens is connected to my MacBookPro, and in terms of display arrangement, the right edge is actually adjacent to the left edge of the laptop display. So the menu does not slide off the right edge of the external monitor and onto the laptop display. It stays with its starting display. FURTHERMORE, it does not happen in Aurora windows located on the laptop display. It ONLY happens on the external monitor. Expected results: The contextual menu should not move at all, regardless of its display placement.
Summary: OS X contextual menu sometimes goes flying → OS X contextual menu goes flying on external monitors
Oh, and I’m on Snow Leopard (10.6.8), if that matters.
UPDATE: I discovered in the course of recording (and playing back) a screencast that the menu does NOT jump up to its initial vertical offset. It appears to jump up twice its height. I’ll upload the screencast so you can see it in all its glory.
Here’s a link to the screencast: http://meyerweb.com/vid/2012/flying-contextual-menus.mov (37.2MB)
That looks funny :-) Do you know if this is a regression ? Would you do the work to find a regression range ? We don't have many people around with such a special setup to test it.
It doesn’t happen in Firefox 15, at least. I’ll see if I can narrow it down further.
We have a tool that helps with this task: https://github.com/mozilla/mozregression
I tried mozregression but when I tried to run a nightly from two weeks ago, I got: moznightly --date=2012-09-01 Downloading nightly from 2012-09-01 Starting nightly ~ > …and that was it. Nothing actually launched. Any idea where the nightlies are stored, so I can try to launch it myself?
I would use as example "mozregression --good=2012-05-01 --args=http://example.com". I use windows but the moznightly fails to start the build as well for me. The nightly is downloaded in the directory where you issued the moznightly command and is extracted in a subdolfer "moznightlyapp"
That’s working, thanks! Working my way backwards now. Is there a calendared list of nightly versions somewhere?
This is a little weird: ~ > mozregression --good=2012-08-22 args=http://localhost/ Downloading nightly from 2012-09-02 How come the dates don’t match up?
You give the tool a starting point, in this case 2012-05-91 and it tries to find the builds with a minimum of downloaded builds. As example: "--good=2012-08-01 --bad=2012-08-30" and the best build to test first is 2012-08-15 because it's in the middle of both dates. Depending of your answer (good or bad) it will download as example 2012-08-07 for testing.
Ahhhh…now THAT makes sense. Working my way through a range right now.
Results! Last good nightly: 2012-08-30 First bad nightly: 2012-08-31 I did not choose to slice more finely, as building source never works out well for me.
The tool should give you a Pushlog URl. Can you post that here ? e.g. http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=762e95608da3&tochange=e794cef56df6 If you did a manual testing of builds you can open about:buildconfig and post the 2 build revisions URLs. e.g. Built from http://hg.mozilla.org/mozilla-central/rev/f36b93c70d05 Thank you very much for doing the work with the regression testing !
Whoops, sorry! Missed that part. Results again: Last good nightly: 2012-08-30 First bad nightly: 2012-08-31 Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=706174d31a02&tochange=fcc533f691e9
Thank you very much, there unfortunately too many checkins in that timeframe and no checking is obvious :-( Marcia: Has QA enough time and the same setup as Eric to try to narrow down this further with the hourly tinderbox builds : ftp://ftp.mozilla.org/pub/firefox/tinderbox-builds/mozilla-central-macosx64/ ?
Status: UNCONFIRMED → NEW
tracking-firefox17: --- → ?
tracking-firefox18: --- → ?
Component: Untriaged → General
Ever confirmed: true
Keywords: regression
Product: Firefox → Core
I should have searched better the first time, this is a dupe of bug 788189
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → DUPLICATE
Dagnabit! I even searched for several combinations of "menu" and "sliding", "flying", "moving", and so on before submitting. Sorry I missed it, and thanks!
You need to log in before you can comment on or make changes to this bug.