Closed Bug 940952 Opened 11 years ago Closed 11 years ago

Fixup selection with apzc pan/zoom

Categories

(Firefox for Metro Graveyard :: Pan and Zoom, defect)

x86_64
Windows 8.1
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED
Firefox 28

People

(Reporter: jimm, Assigned: jimm)

References

Details

(Whiteboard: [release28])

Attachments

(4 files, 6 obsolete files)

      No description provided.
Attached patch patch v.1 (obsolete) — Splinter Review
Attached patch patch v.1 (obsolete) — Splinter Review
Attachment #8335300 - Attachment is obsolete: true
I'm going to let this sit for a bit until we get buffered zoomtorect sorted out for double tap.
Whiteboard: [release28]
Assignee: jmathies → nobody
Depends on: 936905
Attached patch part 1 (obsolete) — Splinter Review
Attachment #8335302 - Attachment is obsolete: true
Attached patch part 2 (obsolete) — Splinter Review
Attached patch part 3 (obsolete) — Splinter Review
Attachment #8336815 - Attachment is patch: true
This patch adds better apzc tracking for front end script. I'm using these to hide selection handles in the front end during pan, zoom and fling operations.
Assignee: nobody → jmathies
Attachment #8336813 - Attachment is obsolete: true
Attachment #8336815 - Attachment is obsolete: true
Attachment #8336816 - Attachment is obsolete: true
Attachment #8337703 - Flags: review?(botond)
This allows selection to stay active after apzc operations. This also fixes a missing return value warning in widget left over from the zoom to rect changes.
Attachment #8337710 - Flags: review?(mbrubeck)
There's also one failing selection test I have to look at.
Summary: Fixup findbar text selection for zoom → Fixup selection with apzc pan/zoom
Comment on attachment 8337710 [details] [diff] [review]
part 3 - fixup selection code to handle pan/zoom v.1

Review of attachment 8337710 [details] [diff] [review]:
-----------------------------------------------------------------

I'd like to try an alternate approach for the new browser property:

::: browser/metro/base/content/bindings/browser.xml
@@ +611,5 @@
> +                        .defaultView
> +                        .QueryInterface(Components.interfaces.nsIInterfaceRequestor)
> +                        .getInterface(Components.interfaces.nsIDOMWindowUtils);
> +          let resX = {}, resY = {};
> +          cwu.getResolution(resX, resY);

You can use "this.scale" to get the resolution here.

@@ +614,5 @@
> +          let resX = {}, resY = {};
> +          cwu.getResolution(resX, resY);
> +          return {
> +            x: scroll.x  / resX.value,
> +            y: scroll.y / resY.value,

It might be nice to return a new Rect object here, so callers have some built-in methods for convenience.

@@ +616,5 @@
> +          return {
> +            x: scroll.x  / resX.value,
> +            y: scroll.y / resY.value,
> +            width: this.contentWindowWidth / resX.value,
> +            height: this.contentWindowHeight / resY.value

I think you should use this.getBoundingClientRect().width and .height here.  Currently this will usually be the same as contentWindowWidth/Height, but I think that will change when we allow pages to change their viewport dimensions.

If we want to get more general, you could write a rectClientToBrowser method (in the style of rectBrowserToClient) and then this property could be implemented as:

  return this.rectClientToBrowser(this.getBoundingClientRect());
Attachment #8337710 - Flags: review?(mbrubeck) → review-
Comment on attachment 8337707 [details] [diff] [review]
part 2 - remove some event cruft from SelectionHelperUI.js

Review of attachment 8337707 [details] [diff] [review]:
-----------------------------------------------------------------

::: browser/metro/base/content/input.js
@@ -32,5 @@
> -// subtle event sequencing differences in this feature when running on
> -// the desktop using the win32 widget backend and the winrt widget backend
> -// in metro. Fixing something in this mode does not insure the bug is
> -// in metro.
> -const kDebugMouseInputPref = "metro.debug.treatmouseastouch";

If you remove this, make sure to also remove TouchModule._treatMouseAsTouch and all references to it.
Attachment #8337707 - Flags: review?(mbrubeck) → review+
(In reply to Matt Brubeck (:mbrubeck) from comment #14)
> Comment on attachment 8337707 [details] [diff] [review]
> part 2 - remove some event cruft from SelectionHelperUI.js
> 
> Review of attachment 8337707 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> ::: browser/metro/base/content/input.js
> @@ -32,5 @@
> > -// subtle event sequencing differences in this feature when running on
> > -// the desktop using the win32 widget backend and the winrt widget backend
> > -// in metro. Fixing something in this mode does not insure the bug is
> > -// in metro.
> > -const kDebugMouseInputPref = "metro.debug.treatmouseastouch";
> 
> If you remove this, make sure to also remove TouchModule._treatMouseAsTouch
> and all references to it.

awesome! more cruft, nice catch.
Implemented all your suggestions.

One of these days I think we need to get into browser.xml and do some cleanup. I'd also like to see the local and remote browsers split up into two separate files.
Attachment #8337710 - Attachment is obsolete: true
Attachment #8338447 - Flags: review?(mbrubeck)
Comment on attachment 8337703 [details] [diff] [review]
part 1 - better, general purpose tracking of apzc activity for front end v.1

Review of attachment 8337703 [details] [diff] [review]:
-----------------------------------------------------------------

It looks like Metro's is the only GeckoContentController implementation that ever used HandlePanBegin() and HandlePanEnd(). Since it's no longer using them, let's get rid of them.

r=me with that change
Attachment #8337703 - Flags: review?(botond) → review+
Attachment #8338447 - Flags: review?(mbrubeck) → review+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: