Closed
Bug 1023041
Opened 10 years ago
Closed 10 years ago
[Window Management] TextSelectionDiag - after moving single caret , the menu won't show again
Categories
(Firefox OS Graveyard :: Gaia::System::Window Mgmt, defect)
Tracking
(Not tracked)
RESOLVED
FIXED
2.1 S2 (15aug)
People
(Reporter: gduan, Assigned: mtseng)
References
Details
Attachments
(2 files, 1 obsolete file)
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
roc
:
review+
|
Details | Diff | Splinter Review |
1. copy or cut any text and touch any place of content, only one caret displaying
2. moving the caret, the dialog disappear
3. stop moving, user try to open the menu again by clicking it. --- failed
User should be able to relaunch the menu by clicking caret.
Reporter | ||
Comment 1•10 years ago
|
||
follow up of bug 938045
Reporter | ||
Updated•10 years ago
|
Blocks: CopyPasteLegacy
Reporter | ||
Comment 3•10 years ago
|
||
Hi Howie,
gecko controls most part of caret's behavior, so does this one.
Hi Morris,
We have offline discussed it before. Is there any duplicate bug?
Flags: needinfo?(gduan) → needinfo?(mtseng)
Assignee | ||
Comment 4•10 years ago
|
||
I don't think there is any duplicate bug. And this part is controlled by gecko as George says.
Flags: needinfo?(mtseng)
Assignee | ||
Comment 5•10 years ago
|
||
UX spec shows we should close utility bubble when user dragging caret and show the bubble when user releasing the caret.
The modification of this patch is firing selection change event with drag/mouseup reason when dragging/releasing touch caret. So we can close the bubble when we got drag reason and show the bubble when we got mouseup reason.
BTW, Closing bubble when got drag reason is handled by bug 1020802.
Comment on attachment 8466003 [details] [diff] [review]
bug1023041
Review of attachment 8466003 [details] [diff] [review]:
-----------------------------------------------------------------
::: layout/base/TouchCaret.cpp
@@ +477,5 @@
> + nsISelection* caretSelection = caret->GetCaretDOMSelection();
> + nsRect focusRect;
> + nsIFrame* caretFocusFrame = caret->GetGeometry(caretSelection, &focusRect);
> + nsRefPtr<nsFrameSelection> fs = caretFocusFrame->GetFrameSelection();
> + if (fs->GetMouseDownState() == aState) {
Don't do this check. nsFrameSelection::SetMouseDownState does it for you.
::: layout/base/TouchCaret.h
@@ +154,5 @@
> + * caret. The reason for setting this state is it will fire drag reason
> + * when moving caret and fire mouseup reason when releasing caret. So that
> + * the display behavior of copy/paste menu becomes more reasonable.
> + */
> + void SetMouseDownState(bool aState);
Call this SetSelectionDragState instead since we're not really dealing with mouse events here.
If you could rename the functionality in nsFrameSelection and related classes to SetDragState etc, that would be great --- as a separate patch.
Attachment #8466003 -
Flags: review?(roc) → review+
Assignee | ||
Comment 7•10 years ago
|
||
Update to address comment.
Attachment #8466003 -
Attachment is obsolete: true
Assignee | ||
Comment 8•10 years ago
|
||
Rename SetMouseDownState to SetDragState.
Attachment #8466902 -
Flags: review?(roc)
Assignee | ||
Updated•10 years ago
|
Attachment #8466901 -
Attachment description: bug1023041-p2 (carry r+: roc) → Part2: Generate correct event when dragging touch caret.(carry r+: roc)
Assignee | ||
Updated•10 years ago
|
Attachment #8466902 -
Attachment description: bug1023041-p1 → Part 1: Rename SetMouseDownState to SetDragState.
Attachment #8466902 -
Flags: review?(roc) → review+
Assignee | ||
Comment 9•10 years ago
|
||
Assignee | ||
Updated•10 years ago
|
Keywords: checkin-needed
Comment 10•10 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/24266caa6b44
https://hg.mozilla.org/integration/mozilla-inbound/rev/feb9b9683e97
Keywords: checkin-needed
https://hg.mozilla.org/mozilla-central/rev/24266caa6b44
https://hg.mozilla.org/mozilla-central/rev/feb9b9683e97
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → 2.1 S2 (15aug)
You need to log in
before you can comment on or make changes to this bug.
Description
•