18395 - [Sched] Editor UI updating should use JS commander nodes

Status: VERIFIED FIXED

(Core :: DOM: Editor, defect, P3)

Description

[Simon Fraser [no longer active]]

We need to change the way we update the editor UI (editing toolbar, menu items)
to use the new commander mechanism that hyatt, hangas and saari have been working
on.

I guess this is 3-4 person-days of work.

Comment 1

[Simon Fraser [no longer active]]

M13

Comment 2

[buster]

*** Bug 16513 has been marked as a duplicate of this bug. ***

Comment 3

[buster]

transferred [dogfood] and [pdt-] from dup bug 16513.

simon, I've recently written a controller in C++ for html text controls, see
mozilla/layout/html/content/src/nsEditorController.h,cpp. So I'd be happy to
help you with this if you have any questions.  Also, paul has written a
controller in javascript, see abCommon.js and widgetglue.js.

Comment 4

[buster]

in fact, maybe we should just factor nsEditorController:  move the core routines
into a controller object in the editor directory that the editor widget uses,
and have a tiny class in layout that embeds one of these as the workhorse for
the html text field controllers (leaving the content/frame specific code in the
tiny layout controller class.)  I think the semantics for when commands are
enable and disabled are identical.  The only difference I really see is that the
editor widget might support more commands than the html text controls, so the
controller for the html text controls would have to override enough of the core
to handle this properly.

Comment 5

[Charles Manske]

*** Bug 21413 has been marked as a duplicate of this bug. ***

Comment 6

[Simon Fraser [no longer active]]

I'm not going to be able to get to this before I come back on Jan 10, but here's
what I think needs to happen:
1. The XUL and JS need to be changed to use command nodes, making use of the
   common commands in globalOverlay.xul where possible. This involves renaming
   lots of our menu items, keys etc.
2. After selection changes, and various other editing operations, we need to
   'dirty' the relevant commands, probably by calling methods on the
    nsXULCommandUpdater in C++, for speed.
3. We need to make sure that the editor controller gets called when appropriate
   (may already happen?)
4. The editor controller needs to be taught about all the editing commends for
   which we have UI. We need to use a more efficient scheme than all the nsString
   member variables in there now.
5. We need to write code to get the enable/disable status of said commands; this
   may require input from joe/charlie/buster

Comment 7

[Charles Manske]

*** Bug 15138 has been marked as a duplicate of this bug. ***

Comment 8

[rubydoo123]

updating summary fields

Comment 9

[Simon Fraser [no longer active]]

Well, I'm trying, but this depends on other stuff that isn't done yet (see bug
dependencies). I'll get as much checked in as I can.

Comment 10

[Simon Fraser [no longer active]]

The frame work for this is now in place, and is being used by the edit menu 
items. There is still considerable work to rig up all the other menu items. Since 
this bug covers the infrastructure, I'm marking it fixed.

Comment 11

[sujay]

Simon, please verify this one...tbanks!

Comment 12

[Simon Fraser [no longer active]]

Verified.

Comment 13

[Pulsebot]

Pushed by ffxbld-merge:
https://hg.mozilla.org/releases/mozilla-beta/rev/7c5133f959ea
[fenix] For https://github.com/mozilla-mobile/fenix/issues/18395: Dismiss contextual menu when entering/exiting Reader Mode