Bug 46696 - Document::nodesFromRect should not consider zoom factor.
Summary: Document::nodesFromRect should not consider zoom factor.
Status: RESOLVED INVALID
Alias: None
Product: WebKit
Classification: Unclassified
Component: DOM (show other bugs)
Version: 528+ (Nightly build)
Hardware: PC OS X 10.5
: P2 Normal
Assignee: Antonio Gomes
URL:
Keywords: Qt
Depends on:
Blocks: 68075
  Show dependency treegraph
 
Reported: 2010-09-27 21:48 PDT by Antonio Gomes
Modified: 2011-10-06 06:50 PDT (History)
4 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Antonio Gomes 2010-09-27 21:48:35 PDT
The primary goal for Document::nodesFromRect is to return all nodes whose area intersect a given rect. The parameters of this methods should be passed in in viewport coordinates. Internally, before performing the rect-based hit test, the method gets contents coordinates off of the original parameters (by considering the scroll offset).

A bug in the current implementation, however, is that it should *not* consider the zoom factor, differently from elementFromPoint.

Reason: no matter the zoom factor one might had set to the view, Document::nodesFromRect() should return the nodes under the exactly position the caller provided.
Comment 1 Kenneth Rohde Christiansen 2010-09-28 04:55:10 PDT
What about scale? Like we scale the QPainter when "zooming" using our tiling implementation.
Comment 2 Benjamin Poulain 2010-09-28 05:36:04 PDT
(In reply to comment #1)
> What about scale? Like we scale the QPainter when "zooming" using our tiling implementation.

That is a very good point.
This scaling also affect the way Qt implement https://bugs.webkit.org/show_bug.cgi?id=44088.
Comment 3 Antonio Gomes 2010-09-28 05:48:13 PDT
(In reply to comment #2)
> (In reply to comment #1)
> > What about scale? Like we scale the QPainter when "zooming" using our tiling implementation.
> 
> That is a very good point.
> This scaling also affect the way Qt implement https://bugs.webkit.org/show_bug.cgi?id=44088.

so when Qt scales the tiled backing store, it does not call webkit's zoom factor?

I will think and test and let you know.
Comment 4 Kenneth Rohde Christiansen 2010-09-28 05:57:25 PDT
(In reply to comment #3)
> (In reply to comment #2)
> > (In reply to comment #1)
> > > What about scale? Like we scale the QPainter when "zooming" using our tiling implementation.
> > 
> > That is a very good point.
> > This scaling also affect the way Qt implement https://bugs.webkit.org/show_bug.cgi?id=44088.
> 
> so when Qt scales the tiled backing store, it does not call webkit's zoom factor?
> 
> I will think and test and let you know.

It does not. There is a difference between scale and zoom. For instance when zooming (let's forget about text-only zoom for now) you do not scale the native-rendered html forms, though we "try" to adjust their sizes which is not always possible.

Scaling, scales everything and this is what you see on mobile devices, even the viewport meta tag uses values such as "initial-scale" :-) and not "initial-zoom..."
Comment 5 Antonio Gomes 2010-09-28 08:49:57 PDT
Well, I have not check the source yet, but for scaling it should work in the same way as it does currently for clicking  with it is scaled: the click point has to be translated to something webcore understands, anyways.
Comment 6 Antonio Gomes 2011-10-06 06:50:25 PDT
In fact, the bug is the other way around. WebCore's page zoom _has_ to be considered when calling Document::nodesFromRect.

The padding values have to be inversely proportional to the current webcore zoom factor.  Same with scaling: but in the scaling case, probably the easier is the caller site to actually pass the padding values adjusted according to the current scale.