WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
100317
Change PopupMenu positioning on Windows such that behaviour on multiple monitors matches Windows standards.
https://bugs.webkit.org/show_bug.cgi?id=100317
Summary
Change PopupMenu positioning on Windows such that behaviour on multiple monit...
Roger Fong
Reported
2012-10-24 18:26:03 PDT
The existing code determines which screen the popup menu "belongs" to by determining which screen the owning application's hwnd belongs to, where ownership is determined by how much of the hwnd is on which screen. To match what most Windows applications do, the owning screen should be whichever screen the drop down button belongs to. To determine which screen an element belongs to in Windows we need to pass in an hwnd for that element. However, since the drop down button is something that WebKit renders there is no hwnd. To remedy this issue, we can temporarily move the popup menu's hwnd to match the position and size of the button, determine the correct screen, and then eventually move it back to the correct final position after the rest of the calculations have been completed. This is all done in the same function call so no rendering of the popup menu occurs between the temporary and final positionings.
Attachments
patch
(7.66 KB, patch)
2012-10-24 18:37 PDT
,
Roger Fong
sam
: review-
eflews.bot
: commit-queue-
Details
Formatted Diff
Diff
revised patch
(7.47 KB, patch)
2012-10-25 15:41 PDT
,
Roger Fong
sam
: review-
Details
Formatted Diff
Diff
made monitorFromHwnd static
(6.65 KB, patch)
2012-10-30 12:36 PDT
,
Roger Fong
sam
: review+
Details
Formatted Diff
Diff
Show Obsolete
(2)
View All
Add attachment
proposed patch, testcase, etc.
Roger Fong
Comment 1
2012-10-24 18:37:52 PDT
Created
attachment 170533
[details]
patch
Radar WebKit Bug Importer
Comment 2
2012-10-24 18:39:39 PDT
<
rdar://problem/12570435
>
EFL EWS Bot
Comment 3
2012-10-24 18:44:58 PDT
Comment on
attachment 170533
[details]
patch
Attachment 170533
[details]
did not pass efl-ews (efl): Output:
http://queues.webkit.org/results/14593039
Early Warning System Bot
Comment 4
2012-10-24 18:45:09 PDT
Comment on
attachment 170533
[details]
patch
Attachment 170533
[details]
did not pass qt-ews (qt): Output:
http://queues.webkit.org/results/14553454
Early Warning System Bot
Comment 5
2012-10-24 18:45:39 PDT
Comment on
attachment 170533
[details]
patch
Attachment 170533
[details]
did not pass qt-wk2-ews (qt): Output:
http://queues.webkit.org/results/14554464
kov's GTK+ EWS bot
Comment 6
2012-10-24 18:46:17 PDT
Comment on
attachment 170533
[details]
patch
Attachment 170533
[details]
did not pass gtk-ews (gtk): Output:
http://queues.webkit.org/results/14552436
Peter Beverloo (cr-android ews)
Comment 7
2012-10-24 19:07:23 PDT
Comment on
attachment 170533
[details]
patch
Attachment 170533
[details]
did not pass cr-android-ews (chromium-android): Output:
http://queues.webkit.org/results/14566416
Sam Weinig
Comment 8
2012-10-24 21:38:04 PDT
Comment on
attachment 170533
[details]
patch View in context:
https://bugs.webkit.org/attachment.cgi?id=170533&action=review
> Source/WebCore/platform/PlatformScreen.h:55 > + FloatRect monitorFromHwnd(HWND);
This will certainly break all the builds except windows, since HWND is a windows type. I'm also not clear on why this should be in platform code, if it is only called from one place.
Roger Fong
Comment 9
2012-10-25 10:37:37 PDT
(In reply to
comment #8
)
> (From update of
attachment 170533
[details]
) > View in context:
https://bugs.webkit.org/attachment.cgi?id=170533&action=review
> > > Source/WebCore/platform/PlatformScreen.h:55 > > + FloatRect monitorFromHwnd(HWND); > > This will certainly break all the builds except windows, since HWND is a windows type.
Right...
> I'm also not clear on why this should be in platform code, if it is only called from one place.
I stuck it there because it looked like many similar methods were coming from there (such as getting the screen from a Widget). Looking at PlatformScreenWin.cpp again, perhaps it makes more sense to just to make the method static and stick it in there. That seems to be what we did for other Windows specific screen info getting methods. Does that seem reasonable or should I just stick it in PopupMenuWin?
Roger Fong
Comment 10
2012-10-25 14:52:17 PDT
Err right, I can't do that of course...static in a source file means no access to anything but source file...right... Anyways, I'll just stick it with PopupMenuWin.h and call it a day.
Roger Fong
Comment 11
2012-10-25 15:41:31 PDT
Created
attachment 170749
[details]
revised patch
Sam Weinig
Comment 12
2012-10-30 10:49:02 PDT
Comment on
attachment 170749
[details]
revised patch View in context:
https://bugs.webkit.org/attachment.cgi?id=170749&action=review
> Source/WebCore/platform/win/PopupMenuWin.cpp:694 > +FloatRect PopupMenuWin::monitorFromHwnd(HWND hwnd) > +{ > + HMONITOR monitor = MonitorFromWindow(hwnd, MONITOR_DEFAULTTOPRIMARY); > + MONITORINFOEX monitorInfo; > + monitorInfo.cbSize = sizeof(MONITORINFOEX); > + GetMonitorInfo(monitor, &monitorInfo); > + return monitorInfo.rcWork; > +}
This can just be a static function, no need to be a member function.
Roger Fong
Comment 13
2012-10-30 12:36:49 PDT
Created
attachment 171501
[details]
made monitorFromHwnd static
Roger Fong
Comment 14
2012-10-31 16:17:30 PDT
Committed here:
http://trac.webkit.org/changeset/133092
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug