Closed
Bug 666977
Opened 14 years ago
Closed 12 years ago
Panning ends selection in progress
Categories
(Firefox for Android Graveyard :: General, defect, P1)
Tracking
(firefox7 affected, firefox8 affected, fennec-)
RESOLVED
WONTFIX
Firefox 9
People
(Reporter: aaronmt, Unassigned)
References
Details
(Whiteboard: [testday-2011-06-24])
Attachments
(3 files, 1 obsolete file)
5.33 KB,
patch
|
mbrubeck
:
review-
|
Details | Diff | Splinter Review |
4.27 KB,
patch
|
mbrubeck
:
review+
|
Details | Diff | Splinter Review |
6.63 KB,
patch
|
mbrubeck
:
review+
|
Details | Diff | Splinter Review |
Mozilla/5.0 (Android; Linux armv7l; rv:7.0a1) Gecko/20110624 Firefox/7.0a1 Fennec/7.0a1
Currently when one pans or scrolls to expose more text for selection it will break the text selection in progress.
Reporter | ||
Updated•14 years ago
|
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → DUPLICATE
Reporter | ||
Comment 2•14 years ago
|
||
Reopening, it seems that bug 666915 is requesting a design for an automatic scroll, where in this bug I'm referring to a manual scroll from the user one leaving the selection up
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Reporter | ||
Updated•14 years ago
|
Status: REOPENED → NEW
Reporter | ||
Updated•14 years ago
|
Priority: -- → P1
Updated•14 years ago
|
Whiteboard: [testday-20110624] → [testday-2011-06-24]
Reporter | ||
Updated•14 years ago
|
Summary: Panning or scrolling breaks text selection in progress → Panning/scrolling or rotation breaks text selection in progress
Reporter | ||
Updated•14 years ago
|
tracking-fennec: --- → ?
Updated•14 years ago
|
tracking-fennec: ? → +
Comment 3•14 years ago
|
||
this patch takes care of maintaining the selection during a pan. Zooming and rotation are probably fairly different, we should get a new bug for that.
Assignee: nobody → blassey.bugs
Attachment #552938 -
Flags: review?(mark.finkle)
Updated•14 years ago
|
Summary: Panning/scrolling or rotation breaks text selection in progress → Panning ends selection in progress
Comment 4•14 years ago
|
||
Looks like I misspoke, this patch should take care of maintaining the selection during panning, zooming and rotation.
Matt, shifting the review to you since mfinkle is on PTO.
Attachment #552938 -
Attachment is obsolete: true
Attachment #553111 -
Flags: review?(mbrubeck)
Attachment #552938 -
Flags: review?(mark.finkle)
Comment 5•14 years ago
|
||
what happens when the handles move offscreen?
Comment 6•14 years ago
|
||
the handles pan off screen with the selection
Comment 7•14 years ago
|
||
Comment on attachment 553111 [details] [diff] [review]
patch
drive-by
What's the purpose of the timer? I mean, what affect are you using it to acheive?
>diff --git a/mobile/chrome/content/common-ui.js b/mobile/chrome/content/common-ui.js
>+ startPt: {x:0, y:0},
{ x:0, y:0 }
>diff --git a/mobile/chrome/content/content.js b/mobile/chrome/content/content.js
> this.cache = this._extractFromRange(range, offset);
> this.contentWindow = contentWindow;
>+ this.offset = offset;
I thought this.cache.offset was used for holding the offset
>+ case "Browser:SelectionMeasure":
>+ {
nit: { up on the case line is the normal style here
>+ let currentDocShell = this.contentWindow.QueryInterface(Ci.nsIInterfaceRequestor).getInterface(Ci.nsIWebNavigation).QueryInterface(Ci.nsIDocShell);
>+ let selcon = currentDocShell.QueryInterface(Ci.nsIInterfaceRequestor).getInterface(Ci.nsISelectionDisplay).QueryInterface(Ci.nsISelectionController);
>+ let selection = selcon.getSelection(1);
>+ let range = selection.getRangeAt(0).QueryInterface(Ci.nsIDOMNSRange);
Why do you use the selection controller to get the selection? why not | this.contentWindow.getSelection() | ?
>+ // If the range didn't have any text, let's bail
>+ if (!this.selectedText.length) {
>+ selection.collapseToStart();
>+ return;
>+ }
I think we started to use | selection.removeAllRanges() | because it does what we really want.
>+ this.cache = this._extractFromRange(range, this.offset);
this.cache = this._extractFromRange(range, this.cache.offset);
Comment 8•14 years ago
|
||
Comment on attachment 553111 [details] [diff] [review]
patch
Review of attachment 553111 [details] [diff] [review]:
-----------------------------------------------------------------
The overall patch looks good. I'll review it again with all of our picky nits addressed.
::: mobile/chrome/content/common-ui.js
@@ +1346,5 @@
> handleEvent: function handleEvent(aEvent) {
> switch (aEvent.type) {
> + case "PanBegin":
> + window.removeEventListener("PanBegin", this, true);
> + if (this.panTimer != 0) {
if (this.panTimer)
@@ +1371,5 @@
> } else {
> + window.addEventListener("PanBegin", this, true);
> + this._start.hidden = true;
> + this._end.hidden = true;
> + this.panTimer = window.setTimeout(function(self, aEvent) {
You don't need to pass aEvent here; it will still be in scope from the outer function.
@@ +1380,4 @@
> }
> break;
> case "TapUp":
> + if (this.target != null) {
if (this.target)
@@ +1407,5 @@
> case "ZoomChanged":
> + {
> + let json = { };
> + try {
> + this.popupState.target.messageManager.sendAsyncMessage("Browser:SelectionMeasure", json);
No need for the "json" local -- just sendAsyncMessage("...", {})
::: mobile/chrome/content/content.js
@@ +1507,5 @@
> + case "Browser:SelectionMeasure":
> + {
> + let currentDocShell = this.contentWindow.QueryInterface(Ci.nsIInterfaceRequestor).getInterface(Ci.nsIWebNavigation).QueryInterface(Ci.nsIDocShell);
> + let selcon = currentDocShell.QueryInterface(Ci.nsIInterfaceRequestor).getInterface(Ci.nsISelectionDisplay).QueryInterface(Ci.nsISelectionController);
> + let selection = selcon.getSelection(1);
Can you use Ci.nsISelectionController.SELECTION_NORMAL here, instead of "1"? (Update: Or see mfinkle's comment.)
Attachment #553111 -
Flags: review?(mbrubeck) → review-
Comment 9•14 years ago
|
||
(In reply to Mark Finkle (:mfinkle) from comment #7)
> Comment on attachment 553111 [details] [diff] [review]
> patch
>
> drive-by
>
> What's the purpose of the timer? I mean, what affect are you using it to
> acheive?
>
> >diff --git a/mobile/chrome/content/common-ui.js b/mobile/chrome/content/common-ui.js
>
> >+ startPt: {x:0, y:0},
actually not using this anymore, just got rid of it
>
> >diff --git a/mobile/chrome/content/content.js b/mobile/chrome/content/content.js
>
> > this.cache = this._extractFromRange(range, offset);
> > this.contentWindow = contentWindow;
> >+ this.offset = offset;
>
> I thought this.cache.offset was used for holding the offset
its not clear to me that this.offset is the same as this.cache.offset
Attachment #553200 -
Flags: review?(mbrubeck)
Comment 10•14 years ago
|
||
Comment on attachment 553200 [details] [diff] [review]
patch
Review of attachment 553200 [details] [diff] [review]:
-----------------------------------------------------------------
::: mobile/chrome/content/content.js
@@ +1430,4 @@
>
> this.cache = this._extractFromRange(range, offset);
> this.contentWindow = contentWindow;
> + this.offset = offset;
I think mfinkle was correct that this.offset will always be equal to this.cache.offset, so you can just remove the former and use the latter. (_extractFromRange always sets the .offset property of its result to the same value you pass in.)
Attachment #553200 -
Flags: review?(mbrubeck) → review+
Updated•14 years ago
|
status-firefox7:
--- → affected
status-firefox8:
--- → affected
Comment 11•14 years ago
|
||
Whiteboard: [testday-2011-06-24] → [testday-2011-06-24][inbound]
Comment 12•14 years ago
|
||
Status: NEW → RESOLVED
Closed: 14 years ago → 14 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 9
Reporter | ||
Comment 13•14 years ago
|
||
Verified Fixed
Mozilla/5.0 (Android; Linux armv7l; rv:9.0a1) Gecko/20110819 Firefox/9.0a1 Fennec/9.0a1
Filed a followup: bug 680419
Status: RESOLVED → VERIFIED
Flags: in-litmus?(martijn.martijn)
Comment 14•14 years ago
|
||
It's very easy to get the selection handles showing up in the wrong position. Just select some text and pan up and down a bit. The handles do no track the selection.
This problem, coupled with the API issues (bug 681387) make me want to revert back to the state we have in Aurora.
Attachment #558520 -
Flags: review?(mbrubeck)
Updated•14 years ago
|
Attachment #558520 -
Flags: review?(mbrubeck) → review+
Comment 15•14 years ago
|
||
Backout: http://hg.mozilla.org/integration/mozilla-inbound/rev/e3ce5dcd2483
Reopening
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Comment 16•14 years ago
|
||
Backout on central: http://hg.mozilla.org/mozilla-central/rev/e3ce5dcd2483
Whiteboard: [testday-2011-06-24][inbound] → [testday-2011-06-24]
Updated•14 years ago
|
Assignee: blassey.bugs → nobody
Updated•13 years ago
|
tracking-fennec: + → -
Reporter | ||
Updated•12 years ago
|
Flags: in-litmus?(martijn.martijn)
Reporter | ||
Updated•12 years ago
|
Status: REOPENED → RESOLVED
Closed: 14 years ago → 12 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•