Closed
Bug 393185
Opened 17 years ago
Closed 14 years ago
Select popups appear off-screen
Categories
(Core :: Widget: Cocoa, defect)
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: mossop, Unassigned)
Details
Attachments
(3 files)
I'm pretty sure this is related to my multi-monitor setup but I often get the popups from select elements appear in a bad place such that most of the popup goes off the edge of my screen. A quick diagram of how my screens are set up: +-------+ | | | 1 | | | +-------+ +-------+ | | | 2 | | | +-------+ Basically if I have Firefox open on monitor 1 and hte select is towards the bottom of the screen then it opens downwards into the blank space below the screen. Presumably Firefox is seeing the extent of the bottom of screen 2 as being valid space even though there is a big gap in the display area. Somehow I have also seen similar effects at the top of screen 2 however I can't reproduce the select opening upwards reliably. Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.9a8pre) Gecko/2007082204 Minefield/3.0a8pre ID:2007082204
Bug 392395 landed very recently (yesterday I think), that could solve your problem. Are you sure your build has that patch? How long have you been seeing this problem?
Comment 2•17 years ago
|
||
It sounds very unlikely that bug 392395 is at all related. From the description the problem here isn't that the popups are opening at the wrong coordinates, but that nothing is being done to try to constrain popups to fit within actual monitors (as opposed to the bounding box of all monitors).
Then perhaps bug 387131 fixed it? That was also checked in yesterday.
Reporter | ||
Comment 4•17 years ago
|
||
My build is from after that checkin. I actually checked and this problem exists in Firefox 2 as well.
Comment 5•17 years ago
|
||
Still happening? I thought this issue was fixed. Chris investigated something similar happening in Camino at the meet-up this summer. Can you attach a testcase with exact steps, in case someone finds another screen for testing?
Comment 6•17 years ago
|
||
Håkan is referring to bug 384657, which was resolved as a dupe of bug 392395, which appears (based on comment 2 and comment 3, as well as comment 4) not to be the cause of this bug. Dave, does bug 384657 sound at all similar to what you were/are experiencing? We really do need a testcase here, too, and Stuart can probably shed some light on it if you can provide one, as IIRC he has access to a multi-monitor configuration on a daily basis. cl
Reporter | ||
Comment 7•17 years ago
|
||
Testcase is pretty simple, any select element demonstrates the bug, I can just use bugzilla's product/component picker. Position the window so the select element is right at the bottom of the top left monitor. Open the select element. It expands down into the space below monitor 1 and to the left of monitor 2. It should expand upwards so it is fully visible.
Comment 8•17 years ago
|
||
(In reply to comment #6) > Stuart can probably shed some light on it if you can provide one, as IIRC > he has access to a multi-monitor configuration on a daily basis. I don't any more (although I could test on one if necessary), but I'm not sure what you want me to shed light on; as I said in comment 2, Dave's explanation seems clear to me, and while I haven't looked at the code, his guess as to the cause in comment 0 sounds highly plausible. There's nothing at all about the behavior as described that suggests a coordinate conversion issue. The bug isn't that it's not opening where the select is, it's that from there it's extending off into an area which is included in the coordinate space defined by the bounding box of all the screens, but not actually within the physical screen. Anyone investigating this problem should find the code that positions the window used for selects, and make sure that the code checks that the window is contained entirely within the union (*not the bounding box*) of all actual monitors. Note by the way that Camino may well not have this problem--and if it does, it's not for the same reason--since we use system menus for selects, and they do a variety of intelligent things with positioning automatically.
Reporter | ||
Comment 9•17 years ago
|
||
Probably should have requested this sooner but this issue is highly irritating for me since I pretty much always run Firefox on my second monitor
Flags: blocking1.9?
Comment 10•17 years ago
|
||
Given comment 4 we are not going to block for this
Flags: blocking1.9? → blocking1.9-
Comment 11•15 years ago
|
||
Can you check if this still happens in a recent nightly? I hope bug 503791 fixes this, if it wasn't fixed before.
Comment 12•14 years ago
|
||
Mossop ...
> Can you check if this still happens in a recent nightly? I hope bug 503791
> fixes this, if it wasn't fixed before.
WFM on windows
Comment 13•14 years ago
|
||
Running 3.6.13 on Windows 7 64bit with two monitors. I can confirm that this is still an issue only when the Firefox window is on the secondary monitor AND one of edges of the secondary (smaller) monitor is below or above the corresponding edge of the main monitor In any other situation, no problem. I will attach a few screen-shots to illustrate
Comment 14•14 years ago
|
||
Monitor "2" is the main one. In this config, the combo is unfolding upwards. The test case added by Dave Townsend (:Mossop) fails.
Comment 15•14 years ago
|
||
Monitor "2" is the main one. In this config, the combo is unfolding downwards. The test case added by Dave Townsend (:Mossop) passes.
Comment 16•14 years ago
|
||
But does it happen for you in Firefox 4.0 betas or nightlys?
Comment 17•14 years ago
|
||
OK. Seems to be OK in Firefox 4 beta. I think this can be closed provided no regression is found until 4.0 release.
Comment 18•14 years ago
|
||
Thanks for the update
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → WORKSFORME
Note that this was a Widget:Cocoa bug, so it really shouldn't have been closed on the basis of a Windows report, since that's using an entirely different widget impl (and screen calculation code). That said, mossop hasn't responded 2008, either, so…
Comment 20•14 years ago
|
||
The bug I think fixed this (bug 503791) wasn't in widget code, it was in cross platform code, if that makes you feel better.
I guess based on the fact it was filed in Widget:Cocoa, and the content of the initial comments, and the fact that no-one ever tried to dupe it back then gave me the impression over the years that everyone thought this was a Mac-specific bug. But it's certainly possible it was a bug in xp code that no-one knew of/connected it to back then ;)
Comment 22•14 years ago
|
||
Happy to help. Though it was Win7 not XP but I guess the code base must be identical as there is no Win7 specific build.
You need to log in
before you can comment on or make changes to this bug.
Description
•