Closed Bug 915279 Opened 8 years ago Closed 8 years ago

Selection monocles position is incorrect after zoom

Categories

(Firefox for Metro Graveyard :: Input, defect)

x86_64
Windows 8.1
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 940952

People

(Reporter: jimm, Assigned: jimm)

References

Details

(Whiteboard: [release28] [front-end])

Attachments

(1 file)

STR:

1) open a page with some text
2) select some text
3) zoom in a bit
Blocks: 915724
No longer blocks: metro-apzc
How are the selection monocles drawn in Metro? Are they a thing in Gecko or are they overlaid using Windows APIs on top? It looks to me like they are drawn using Gecko so if you make them position:absolute relative to the content document they should stay in place when you pan around.

I'm also CC'ing Ehsan because we were discussing text selection and how to do it consistently across all platforms last week, and he might be interested in knowing what's happening here.
(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #1)
> How are the selection monocles drawn in Metro? Are they a thing in Gecko or
> are they overlaid using Windows APIs on top? It looks to me like they are
> drawn using Gecko so if you make them position:absolute relative to the
> content document they should stay in place when you pan around.
> 
> I'm also CC'ing Ehsan because we were discussing text selection and how to
> do it consistently across all platforms last week, and he might be
> interested in knowing what's happening here.

This is a front end issue which is where we manage the monocles. We need to hide them at the start of a pan or zoom and reposition/display when the apz operation is complete.
(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #1)
> How are the selection monocles drawn in Metro? Are they a thing in Gecko or
> are they overlaid using Windows APIs on top? It looks to me like they are
> drawn using Gecko so if you make them position:absolute relative to the
> content document they should stay in place when you pan around.

How would that work?  Zooming should change the coordinates used on the position:absolute element.

> I'm also CC'ing Ehsan because we were discussing text selection and how to
> do it consistently across all platforms last week, and he might be
> interested in knowing what's happening here.

I am, yes!
(In reply to :Ehsan Akhgari (needinfo? me!) from comment #3)
> (In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #1)
> > How are the selection monocles drawn in Metro? Are they a thing in Gecko or
> > are they overlaid using Windows APIs on top? It looks to me like they are
> > drawn using Gecko so if you make them position:absolute relative to the
> > content document they should stay in place when you pan around.
> 
> How would that work?  Zooming should change the coordinates used on the
> position:absolute element.
> 
I would hope that coords in text ranges would update accordingly after the apz transforms due to a zoom or pan. If not, we have a another problem on our hands.
So panning works ok since the the monocles are positioned at screen coords, and after panning the selection text rect appears to be correct. I can pan the page and then select and the monocles are positioned correctly. I'm guessing this is due to the content scroll position updating we do when we move the display port around. 

With zoomed content though the coords are wrong. We can probably skip around this by disabling selection while zoomed for now. That kind of sucks but if there's no easy fix we may have to wait until all the selection code is down in platform.
Duplicate of this bug: 920077
Whiteboard: [block28] [front-end]
Assignee: nobody → jmathies
Attached patch wipSplinter Review
Zoom is a little messed up currently making this hard to test. Posting a wip that kinda works.
Whiteboard: [block28] [front-end] → [release28] [front-end]
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 940952
OS: Windows 8 Metro → Windows 8.1
You need to log in before you can comment on or make changes to this bug.