Bug 1595425 Comment 9 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

(In reply to Emilio Cobos Álvarez (:emilio) from comment #7)
> Ah, yes, it does help a bunch!
> 
> I see... So this should only happen when there's text selected, or the input is focused, right?
> 
> This seems to have been introduced in bug 1568996, and it seems expected as far as I can tell... But I don't know if we could avoid it in some cases? It does seem unfortunate than setting the value to the empty string has to flush layout, as the selection should be completely removed.
> 
> Probably Makoto or Masayuki, which are way more familiar with this code, could help more than me :)

FrameSelection::MoveCaret doesn't work when frame is dirty since editor holds script blocker when callign FrameSeleciton::MoveCaret. (Before landing bug 1568996, although MoveCaret calls pending flush, layout won't flushed due to holding script block.)

Also, If this script is from content, this doesn't occur. Because we don't use `DeleteSelectionAsAction` and add transaction history.  If from XUL, since we have to add transaction, we use `DeleteSelectionAsAction` now. But this case may have to add new method to clear value, not using `mozilla::TextEditor::DeleteSelectionAsAction` in `mozilla::TextControlState::SetValueWithTextEditor` (or add something hold to block flush layout.)
(In reply to Emilio Cobos Álvarez (:emilio) from comment #7)
> Ah, yes, it does help a bunch!
> 
> I see... So this should only happen when there's text selected, or the input is focused, right?
> 
> This seems to have been introduced in bug 1568996, and it seems expected as far as I can tell... But I don't know if we could avoid it in some cases? It does seem unfortunate than setting the value to the empty string has to flush layout, as the selection should be completely removed.
> 
> Probably Makoto or Masayuki, which are way more familiar with this code, could help more than me :)

FrameSelection::MoveCaret doesn't work when frame is dirty since editor holds script blocker when callign FrameSeleciton::MoveCaret. (Before landing bug 1568996, although MoveCaret calls pending flush, layout won't flushed due to holding script block.)

Also, If this script is from content, this doesn't occur. Because we don't use `DeleteSelectionAsAction` and doesn't add transaction history.  If from XUL, since we have to add transaction, we use `DeleteSelectionAsAction` now. But this case may have to add new method to clear value, not using `mozilla::TextEditor::DeleteSelectionAsAction` in `mozilla::TextControlState::SetValueWithTextEditor` (or add something hold to block flush layout.)

Back to Bug 1595425 Comment 9