Closed
Bug 852619
Opened 11 years ago
Closed 11 years ago
Tap off form input to clear caret selection should clear focus
Categories
(Firefox for Metro Graveyard :: Input, defect)
Tracking
(Not tracked)
RESOLVED
FIXED
Firefox 22
People
(Reporter: jimm, Assigned: jimm)
References
Details
(Whiteboard: [selection])
Attachments
(1 file, 1 obsolete file)
7.62 KB,
patch
|
ally
:
review+
|
Details | Diff | Splinter Review |
STR: 1) click a text input bringing up the caret 2) click off the form to remove focus result: the caret is cleared but the form maintains focus.
Assignee | ||
Comment 1•11 years ago
|
||
Similarly, when focus is active in an input and the focus selection monocles are up, taping off the input doesn't clear selection.
Assignee | ||
Comment 2•11 years ago
|
||
Assignee: nobody → jmathies
Attachment #726862 -
Flags: review?(ally)
Assignee | ||
Comment 3•11 years ago
|
||
Updated post some review changes in dependent bugs.
Attachment #726862 -
Attachment is obsolete: true
Attachment #726862 -
Flags: review?(ally)
Attachment #727209 -
Flags: review?(ally)
Assignee | ||
Updated•11 years ago
|
Whiteboard: [selection]
Comment 4•11 years ago
|
||
Comment on attachment 727209 [details] [diff] [review] tap focus adjustments Review of attachment 727209 [details] [diff] [review]: ----------------------------------------------------------------- I'm not terribly familiar with the selection code, but this seems solid to me. Couple nits, and is it possible to write a test for this? ::: browser/metro/base/content/Util.js @@ +178,5 @@ > /* > * Rect and nsIDOMRect utilities > */ > > + cleanRect: function cleanRect() { nit - can we call this getCleanRect()? the current name is ambiguous about whether 'clean' is a noun or a verb. ::: browser/metro/base/content/contenthandlers/SelectionHandler.js @@ +316,5 @@ > > /* > + * Selection clear message handler > + * > + * @param aClearFocus requests that the focus also be cleared. looks like you have a trailing whitespace of some sort ::: browser/metro/base/content/helperui/SelectionHelperUI.js @@ +366,5 @@ > }, > > /* > * closeEditSessionAndClear > * more different trailing whitespace @@ +371,5 @@ > * Closes an active edit session and shuts down. Clears any selection region > * associated with the edit session. > + * > + * @param aClearFocus bool indicating if the selection handler should also > + * clear the focus element. optional, the default is false. Why did you choose false as the default? @@ +376,4 @@ > */ > + closeEditSessionAndClear: function closeEditSessionAndClear(aClearFocus) { > + let clearFocus = aClearFocus || false; > + this._sendAsyncMessage("Browser:SelectionClear", { clearFocus: clearFocus }); (limitation of reviewer's brain) if clearFocus is false, does the second argument become 'clearFocus:false', or 'false:false'. Might you really want {"clearFocus": clearFocus} ?
Attachment #727209 -
Flags: review?(ally) → review+
Assignee | ||
Comment 5•11 years ago
|
||
(In reply to :Ally Naaktgeboren from comment #4) > Comment on attachment 727209 [details] [diff] [review] > tap focus adjustments > > Review of attachment 727209 [details] [diff] [review]: > ----------------------------------------------------------------- > > I'm not terribly familiar with the selection code, but this seems solid to > me. Couple nits, and is it possible to write a test for this? Yes, tests will get covered in bug 852090. > @@ +371,5 @@ > > * Closes an active edit session and shuts down. Clears any selection region > > * associated with the edit session. > > + * > > + * @param aClearFocus bool indicating if the selection handler should also > > + * clear the focus element. optional, the default is false. > > Why did you choose false as the default? The code has always depended on the old way of doing things. I added new functionality so I kept the old default. > > @@ +376,4 @@ > > */ > > + closeEditSessionAndClear: function closeEditSessionAndClear(aClearFocus) { > > + let clearFocus = aClearFocus || false; > > + this._sendAsyncMessage("Browser:SelectionClear", { clearFocus: clearFocus }); > > (limitation of reviewer's brain) if clearFocus is false, does the second > argument become 'clearFocus:false', or 'false:false'. Might you really want > {"clearFocus": clearFocus} ? Apparently not since this works. :) I'll ask mbrubeck about this today in irc, it's an interesting question.
Comment 6•11 years ago
|
||
See https://developer.mozilla.org/en-US/docs/JavaScript/Guide/Working_with_Objects, you would need to do let params = {}; params[clearFocus] to get { false: false }; properties are always strings (only JSON requires them to be quoted).
Assignee | ||
Comment 7•11 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/51d0ff5dc48e
Comment 8•11 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/51d0ff5dc48e
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 22
Updated•10 years ago
|
OS: Windows 8 Metro → Windows 8.1
You need to log in
before you can comment on or make changes to this bug.
Description
•