340379 - accessible/base depends on platform-specific modules

Status: RESOLVED INCOMPLETE

(Core :: Disability Access APIs, defect)

Description

[Håkan Waara]

Today, the accessible/base code depends directly on its subclasses.

For example, see http://landfill.mozilla.org/mxr-test/mozilla/source/accessible/src/base/nsAccessibilityService.cpp#76

This is a problem in the mac module, because I need to use a lot of objective-c, and for that to work c++-only source can't directly include it.

I discussed with Pike and Neil in #developers, and the way around it could be to register all wrap classes with the component manager, and then simply do_CreateInstance them in the base/ code.

the *wrap classes already implement nsISupports, so I don't think it's too much work.

Comment 1

[[e-mail]]

The other approach (which was Pike's idea) is to create a new header file which declares NS_NewRootAccessibleWrap(nsIAccessible** aResult) etc. which you would include in nsAccessibilityService.cpp and use like this:
// CreateRootAccessible(... nsIAccessible **aRootAcc);
return parentTreeItem ?
    NS_NewDocAccessibleWrap(aRootAcc) :
    NS_NewRootAccessibleWrap(aRootAcc);

You could also include it in nsRootAccessibleWrap.cpp and define it:
NS_NewRootAccessibleWrap(nsIAccessible** aResult)
{
  nsRefPtr<nsRootAccessibleWrap> acc = new nsRootAccessibleWrap();
  if (!acc)
    return NS_ERROR_OUT_OF_MEMORY;

  nsresult rv = acc->Init();
  if (NS_FAILED(rv))
    return rv;

  NS_ADDREF(*aResult = acc);
  return NS_OK;
}

Or you could write an extra cpp file to define all the NS_NewWrap functions.

Comment 2

[Håkan Waara]

Classes inside /base depend on wrap classes. For example:

http://landfill.mozilla.org/mxr-test/mozilla/source/accessible/src/base/nsBaseWidgetAccessible.h#56

Comment 3

[Håkan Waara]

I followed the hierarchy up, starting from the nsRootAccessible just to see how xp-code and native code inherits from one another. Here's the result (base class at the top, so start reading from the bottom):

nsAccessNode (xp) :
nsAccessNodeWrap (native) :
nsAccessible (xp) :
nsAccessibleWrap (native) :
nsBlockAccessible (xp) :
nsDocAccessible (xp) :
nsDocAccessibleWrap (native) :
nsRootAccessible (xp) :
nsRootAccessibleWrap (native)

So the conclusion is that for each specialization of the base classes, a pass is made down to the native code, to give them the ability to override something, and then back up again. 

Here's my crazy idea: Maybe the hierarchy can be reordered? Perhaps we could make so *all* the native classes come at the end. As it is now, every class adds new "abilities", so the abstract base classes would need to add those abilities, and the native code override whatever needs to be overridden at the end.

Like this:

class nativeAccessibleClass : public someOtherNativeClass, // the other native class already implements a few xp classes
                              public someXPClass // but we need this one as well

Take for example nsDocAccessibleWrap. It would be like this:

class nsDocAccessibleWrap : public nsAccessibleWrap, // native
                            public nsAccessNodeWrap, // native
                            public nsBlockAccessible, // xp
                            public nsDocAccessible // xp
                        
nsDocAccessibleWrap's inheritance would thus be:

nsAccessNode (xp)
nsAccessible (xp):
nsAccessibleWrap (native), nsAccessNodeWrap (native), nsBlockAccessible (xp), nsDocAccessible (xp) :
nsDocAccessibleWrap (native) :

It would flatten the hierarchy a bunch. Today every class inherits just *one* class, which is why the hierarchy is so deep.

Is this feasible? I think it should work in theory ;-), although it would need some major reordering. Especially the classes in base/ would have to be done so they're more abstract. AFAICS, All the logic and code should still apply though, but things would be inherited in another order. 

Of course, this is complicated stuff so I don't claim to have the best solution...

In the end each platform-specific module would be independent though, and possibly much simpler to maintain both for each platform and in the base code (less classes, more code sharing).

For info about the full hierarchy, there's Aaron's doc at http://www.mozilla.org/access/architecture

Comment 4

[Håkan Waara]

Sorry for the long post and bad indenting, I tried to minimize it.

One clarification: many classes inherit more than one class, but there is still much potential to cut down on the tree depth in favor of breadth.

Comment 5

[Håkan Waara]

This is a major change to the accessibility architecture, and might therefore not be realistic for me to change right now. 

However, if we're overhauling the arch anyway, it's really something we should move towards, imho... It could be done incrementally. (Starting to make the top classes abstract, and working our way down the hierarchy to flatten it.)

I think I've found a workaround for mac.

Comment 6

[Håkan Waara]

IMHO, comment 3 would be good a long-term goal.  But I'm not blocked by this any longer, so I won't work on it (now).

Comment 7

[David Bolter [:davidb] (NeedInfo me for attention)]

Mass un-assigning bugs assigned to Aaron.

Comment 8

[David Bolter [:davidb] (NeedInfo me for attention)]

AUTO-CLOSED. This bug untouched for over 2000 days. Please reopen if you can confirm the bug and help it progress.