Closed Bug 393185 Opened 17 years ago Closed 14 years ago

Select popups appear off-screen

Categories

(Core :: Widget: Cocoa, defect)

Product:
Core
Component:
Widget: Cocoa
Platform:
x86
macOS
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: mossop, Unassigned)

Details

Attachments

(3 files)

testcase
841 bytes, text/html
Details
Screen configuration where it fails.
29.95 KB, image/png
Details
Screen configuration where it passes.
43.66 KB, image/png
Details 
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?
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.
My build is from after that checkin. I actually checked and this problem exists in Firefox 2 as well.
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?
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
Attached file testcase — 
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.
(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.
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?
Given comment 4 we are not going to block for this
Flags: blocking1.9? → blocking1.9-
Assignee: joshmoz → nobody
Can you check if this still happens in a recent nightly? I hope bug 503791 fixes this, if it wasn't fixed before.
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
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
Monitor "2" is the main one.

In this config, the combo is unfolding upwards. The test case added by Dave Townsend (:Mossop) fails.
Monitor "2" is the main one.

In this config, the combo is unfolding downwards. The test case added by Dave Townsend (:Mossop) passes.
But does it happen for you in Firefox 4.0 betas or nightlys?
OK. Seems to be OK in Firefox 4 beta. I think this can be closed provided no regression is found until 4.0 release.
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…
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 ;)
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.

Attachment

General

Creator:
Created:
Updated:
Size: