Closed
Bug 1421318
Opened 7 years ago
Closed 5 years ago
Google Translate: Unable to insert cursor into block of text
Categories
(Core :: DOM: Editor, defect, P2)
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: mellis, Unassigned)
References
(Blocks 1 open bug, )
Details
(Whiteboard: [DevAdvocacy][webcompat])
Steps to reproduce:
1. Visit Google Translate in the FF browser
2. copy-paste a block of text into the left-hand column for translation.
3. Once translated, attempt to double-click somewhere inside the block of text in order to edit the inputted text.
Result: Can highlight all, but cannot insert cursor
Expected Result: Double click inside block of text to insert cursor.
|
Reporter | |
Updated•7 years ago
|
Whiteboard: [Dev Advocacy]
|
|
Reporter | |
Updated•7 years ago
|
Whiteboard: [Dev Advocacy] → [Dev Advocacy], [DevAdvocacy]
|
||
Comment 1•7 years ago
|
||
I can reproduce when using the translate widget on the google search results page:
https://www.google.com/search?ei=P5IdWubgGerMjwTFgYSYCQ&q=google+translate&oq=google+translate
Whiteboard: [Dev Advocacy], [DevAdvocacy] → [Dev Advocacy], [DevAdvocacy][needsdiagnosis]
|
|
Reporter | |
Comment 3•7 years ago
|
||
Correction: This bug effects the Google Translate Widget in the SERP, but not the G.Translate site
|
|
Reporter | |
Comment 4•7 years ago
|
||
TY MIKE!
|
||
Comment 5•7 years ago
|
||
This is due to Chrome and Firefox having different default selection behavior. What's happening is that their page is using JS to select all of the text on-click, because the textarea element has a "tob.poc" action:
<textarea class="tw-ta tw-text-small" id="tw-source-text-ta" autocapitalize="off" autocomplete="off" autocorrect="off" rows="1" spellcheck="false" jsaction="focus:tob.pon;blur:tob.pof;tob.poc"></textarea>
tob.poc is ultimately a click handler which selects the text:
function() {
document.activeElement != this.Hi.Ie && this.Hi.Ie.focus();
this.Hi.Ie.setSelectionRange(0, this.$().length)
}
However, Chrome seems to be ignoring the setSelectionRange call *if* the text is already selected, and the user is doing a simple click in one spot to de-select the text. Firefox does not ignore the call in this case, so the text remains selected. WebKit follows Chrome's behavior, while Edge follows ours. Perhaps we ought to adopt the Chrome behavior?
Flags: needinfo?(twisniewski)
|
|
||
Comment 6•7 years ago
|
||
Thanks Tom. Let's move this to Core::Editor.
Component: Desktop → Editor
Product: Tech Evangelism → Core
Version: Firefox 57 → 57 Branch
|
|
||
Updated•7 years ago
|
Whiteboard: [Dev Advocacy], [DevAdvocacy][needsdiagnosis] → [Dev Advocacy], [DevAdvocacy][webcompat]
|
||
Updated•7 years ago
|
Priority: -- → P2
|
||
Comment 7•6 years ago
|
||
Migrating Webcompat whiteboard priorities to project flags. See bug 1547409.
Webcompat Priority: --- → ?
|
|
||
Comment 8•6 years ago
|
||
See bug 1547409. Migrating whiteboard priority tags to program flags.
|
|
||
Comment 9•5 years ago
|
||
It looks like Google fixed this (?maybe?). Tom could you make a reduced test case of your findings in case the interop bug still reproduces.
Blocks: 1545051
Webcompat Priority: ? → ---
Whiteboard: [Dev Advocacy], [DevAdvocacy][webcompat] → [DevAdvocacy][webcompat]
|
||
Comment 11•5 years ago
|
||
Alas, it seems that I didn't provide enough detail at the time to make a test-case, as I just wrote one based on comment 5 and it's not reproducing the problem (even in Firefox 56).
Flags: needinfo?(twisniewski)
|
|
||
Comment 12•5 years ago
|
||
OK, thanks for checking. Let's go ahead and close then.
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•