Page zoom is taken into account when setting event.pageX and pageY, but event.offestX and offsetY are not fixed up accordingly.
Created attachment 28817 [details]
Testcase: zoom, then hover and look at the offsetX/offsetY numbers
offsetX/offsetY are also used for slider thumb tracking, so this breaks that.
Bug 24733 fixes related issues with pageX, pageY
Created attachment 28838 [details]
This also fixes bug 24748.
Doesn't this patch need tests?
There's no way to test full page zoom as the user sees it. That should be an RFE for DumpRenderTree.
Hmm, maybe zoom: style can be used to test.
(In reply to comment #7)
> Hmm, maybe zoom: style can be used to test.
That's what existing zoom fixes use, as far as I can tell.
Comment on attachment 28838 [details]
> + * dom/Document.cpp:
> + (WebCore::Document::elementFromPoint):
> + Document::elementFromPoint() needs to take full-page zoom into account.
How can the caller tell that the x and y here are supposed to be "non-zoomed" coordinates? Is there a naming scheme for such things?
> + float zoomFactor = frame() ? frame()->pageZoomFactor() : 1.0f;
It's becoming more and more clear that the zoom factor needs to be stored in the Document or the FrameView, not the Frame.
Also, elementFromPoint seems like it should be a simple forwarder to a function in FrameView or RenderView. We may be obliged to put some of these operations in the DOM because of the public DOM API, but internally we should try to make a bit of model/view separation.
Where are the regression tests for these changes?
I am really tempted to say review- because of the lack of regression tests, but I'm going to say review+ counting on you adding them.
I will add some tests with this commit, but it's not possible to fully test FPZ via DRT. I filed bug 24761.