Closed
Bug 1114853
Opened 10 years ago
Closed 10 years ago
[Text Selection] when calling input.focus(), the text selection bubble would show up randomly
Categories
(Firefox OS Graveyard :: Gaia, defect, P2)
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: eragonj, Assigned: mtseng)
References
Details
Attachments
(6 files, 4 obsolete files)
1.67 KB,
patch
|
roc
:
review+
TYLin
:
feedback+
|
Details | Diff | Splinter Review |
1.21 KB,
patch
|
roc
:
review+
TYLin
:
feedback+
|
Details | Diff | Splinter Review |
1.04 KB,
patch
|
roc
:
review+
|
Details | Diff | Splinter Review |
1.66 KB,
patch
|
Details | Diff | Splinter Review | |
1.93 KB,
patch
|
Details | Diff | Splinter Review | |
46 bytes,
text/x-github-pull-request
|
Details | Review |
When writing patch for bug 1103809, I noticed that if we focus on input programmatically, the text selection bubble would show up randomly without any reason.
[STR]
With bug 1103809 applied first.
1. Go to settings app > call settings.
2. click on voicemail menuItem.
3. click back button and go back to previous panel.
4. repeat step 2 & step 3 and you will see this inconsistent behavior.
[Expected Result]
Text selection bubble should show up correctly no matter how.
[Actual Result]
Text selection bubble would show up randomly.
Comment 1•10 years ago
|
||
Hi Morris,
I found that, if js call selection related api, such as input.focus + input.setSelectionRange / input.select, the bubble will show up, however, it would not disappear if I click other place with user-select: none, there would be no selectionstatechanged event pop out from gecko.
Only if I click one of the buttons, it would become normal again.
could you kindly help to check this issue?
Blocks: CopyPasteLegacy
Flags: needinfo?(mtseng)
Assignee | ||
Comment 2•10 years ago
|
||
Attachment #8541125 -
Flags: feedback?(tlin)
Assignee | ||
Comment 3•10 years ago
|
||
Attachment #8541126 -
Flags: feedback?(tlin)
Assignee | ||
Comment 4•10 years ago
|
||
Attachment #8541127 -
Flags: feedback?(tlin)
Assignee | ||
Comment 5•10 years ago
|
||
Attachment #8541128 -
Flags: feedback?(tlin)
Assignee | ||
Comment 6•10 years ago
|
||
Attachment #8541129 -
Flags: feedback?(tlin)
Assignee | ||
Comment 7•10 years ago
|
||
Assignee | ||
Updated•10 years ago
|
Flags: needinfo?(mtseng)
Attachment #8541132 -
Flags: feedback?(gduan)
Updated•10 years ago
|
Attachment #8541125 -
Flags: feedback?(tlin) → feedback+
Updated•10 years ago
|
Attachment #8541126 -
Flags: feedback?(tlin) → feedback+
Comment 8•10 years ago
|
||
Comment on attachment 8541127 [details] [diff] [review]
Part 3: Reset mSelectionVisibleInScrollFrames when visibility set to false.
Review of attachment 8541127 [details] [diff] [review]:
-----------------------------------------------------------------
Thanks for fixing this variable which I added.
::: layout/base/SelectionCarets.cpp
@@ +293,5 @@
> (aVisible ? "shown" : "hidden"));
> return;
> }
>
> + if (aVisible == false) {
Nit: if (!aVisible)
Attachment #8541127 -
Flags: feedback?(tlin) → feedback+
Comment 9•10 years ago
|
||
Comment on attachment 8541128 [details] [diff] [review]
Part 4: Bail out if selections are mismatch.
Review of attachment 8541128 [details] [diff] [review]:
-----------------------------------------------------------------
Nice! nsCaret and TouchCaret already did this.
Attachment #8541128 -
Flags: feedback?(tlin) → feedback+
Updated•10 years ago
|
Attachment #8541129 -
Flags: feedback?(tlin) → feedback+
Assignee | ||
Comment 10•10 years ago
|
||
fix nit.
Attachment #8541127 -
Attachment is obsolete: true
Attachment #8541147 -
Flags: review?(roc)
Assignee | ||
Updated•10 years ago
|
Attachment #8541125 -
Flags: review?(roc)
Assignee | ||
Updated•10 years ago
|
Attachment #8541126 -
Flags: review?(roc)
Assignee | ||
Updated•10 years ago
|
Attachment #8541128 -
Flags: review?(roc)
Assignee | ||
Updated•10 years ago
|
Attachment #8541129 -
Flags: review?(roc)
Assignee | ||
Updated•10 years ago
|
Assignee: nobody → mtseng
Status: NEW → ASSIGNED
Priority: -- → P2
Comment on attachment 8541125 [details] [diff] [review]
Part 1: Change rule of forcing dispatch selection state changed event.
Review of attachment 8541125 [details] [diff] [review]:
-----------------------------------------------------------------
::: dom/browser-element/BrowserElementChildPreload.js
@@ +625,5 @@
> }
>
> + // If we select something and selection range is visible, we set the
> + // forceDispatchSelectionStateChanged flag as true to dispatch the
> + // next SelecitonChange event so that the parent side can
SelectionChange
Attachment #8541125 -
Flags: review?(roc) → review+
Attachment #8541126 -
Flags: review?(roc) → review+
Attachment #8541128 -
Flags: review?(roc) → review+
Attachment #8541129 -
Flags: review?(roc) → review+
Attachment #8541147 -
Flags: review?(roc) → review+
Assignee | ||
Comment 12•10 years ago
|
||
Update to addressed comment
Attachment #8541125 -
Attachment is obsolete: true
Assignee | ||
Comment 13•10 years ago
|
||
Assignee | ||
Comment 14•10 years ago
|
||
Fix test fail.
Attachment #8541128 -
Attachment is obsolete: true
Assignee | ||
Comment 15•10 years ago
|
||
Comment 17•10 years ago
|
||
Comment 18•10 years ago
|
||
Hi Alive,
could I have your review for this patch?
Thanks.
Attachment #8541132 -
Attachment is obsolete: true
Attachment #8541132 -
Flags: feedback?(gduan)
Attachment #8543841 -
Flags: review?(alive)
Comment 19•10 years ago
|
||
Attachment #8543841 -
Flags: review?(alive)
You need to log in
before you can comment on or make changes to this bug.
Description
•