https://bugzilla.wikimedia.org/show_bug.cgi?id=72108
--- Comment #8 from Roan Kattouw <[email protected]> --- (In reply to D Chan from comment #7) > 1. Unicorning is triggered by DM selection changes only if ve.dm.Surface > 'insertionAnnotationsChange' is fired: that's how ve.ce.Surface > renderSelectedContentBranchNode gets called. But moving to a continuation > position doesn't necessarily mean the insertion annotations will have > changed. > > 2. DOM-originated selection changes are applied to the DM with a render lock > in place. This has to be so, because there are more DOM cursor positions > than DM ones. > > 3. Therefore, perhaps we should make continuation unicorning happen even if > there is a render lock in place, probably with its own emit event. > Both #1 and #2 are good reasons for #3. Maybe this could be done in setSelection()? > 4. The DM needs to know for which annotations will browser continuation > suffice. The merged code in ve.ce.ContentBranchNode getRenderedContents > special-cases links only, whereas the patchset above adds a property to the > annotation classes. > Yeah there is a CE property for this (forceContinuation), but I guess my proposed solution to #3 may require the DM know. I would still prefer, though, to find a way to keep this knowledge in CE, possibly by having DM emitting too many events that are then filtered by CE. > Continuation unicorns can give us short-term consistency, but not the > desired "word-break" behaviour. If we want to do go with the short-term fix, > we should define exactly what behaviour to implement. In the longer term, a > UI change might provide a better experience -- e.g. show the user more > explicitly that they're inside link continuation and let them cursor/click > out of it. Yeah we have talked about this in the past. I will try to find this and show it to you, it's scarily analogous to unicorns (before unicorns were invented). -- You are receiving this mail because: You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
