169319 - Expose `WSRunScanner` functinonality so other classes can use it

Status: RESOLVED WONTFIX

(Core :: DOM: Editor, defect)

Description

[Akkana Peck]

In bug 96470, Joe says:

> So *both* the find code and the copy code eventually need to have the 
> nsWSRunObject thingy from editor pulled in.

I ask:
> Joe: if you're moving nsWSRunObject anyway, any chance it can be scriptable?  I
> have code in EdReplace.js that mostly duplicates the whitespace-detection code
> in nsFind.cpp; if the interface could somehow be abstracted into a scriptable
> class then all these objects could call the same code.

and Joe replies:
> I guess so.  Nonoe of this will happen for moz1.0 anyway.  After that we should 
> get together and plan out what functionality the find code and the copy code 
> need, and design the right interface.  Then I'll do brain surgery on the 
> whitespace code and put the juicy bits over where content and find can find them.

I need a tracking bug for that issue so I know when the dependency is ready so I
can proceed on bug 96470.  This is it.

Comment 1

[Stephen Donner [:stephend] Not actively reading bugmail]

Mass-removing myself from cc; search for 12b9dfe4-ece3-40dc-8d23-60e179f64ac1 or any reasonable part thereof, to mass-delete these notifications (and sorry!)

Comment 2

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

In these days, compatibility between browsers is more important than before. And editor utils may need to treart temporary state for checking whether additional work is required for expected result. Therefore, it's not reasonable to share editor utils with outside of the editor module (opposite cases are fine, though).