502323 - 3.6 build issues

Status: RESOLVED DUPLICATE of bug 525730

(Core Graveyard :: XForms, defect)

Description

[Dion Sole]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.1) Gecko/20090624 Firefox/3.5 (.NET CLR 3.5.30729)
Build Identifier: 

Due to various changes in the 3.5 mozilla code, bits of XForms don't build any more:

nsIXPathEvaluatorInternal::CreateExpression() now expects nsTArrays for its namespaceURI and contractID parameters. In nsXFormsUtils::CreateExpression, the code still uses nsStringArray and nsCStringArray, which fails to build. There may be other similar places, but I haven't checked yet. It might be a good idea to convert all nsStringArray and nsCStringArrays to be template arrays, similar to bug 461047.

nsXFormsModelElement fails to build now as it includes nsStringEnumerator.h, which includes an internal linkage header and thus fails to build. I can't see any string enumerators actually being used in the model code, and removing the include doesn't cause any issues.

nsCStringArray no longer has a ParseString() function, so the schema loading fails. ParseString() is now a utility function, but it also now only accepts one delimiter, not multiple as the old code allowed.

I've patched these issues, but I'm not gonna submit the patches yet because there might be more similar issues.

Reproducible: Always

Comment 1

[Dion Sole]

More stuff:

nsIDOMNSDocument no longer has GetBoundingBoxFor() (see bug 340571 for reasons why), and so nsXFormsMessageElement fails. Easily fixed by changing to using nsIDocument::GetBoundingBoxFor() instead.

Similarly, lots of the JS stuff used getBoundingBoxFor(), and they'll no longer work in 3.5. If they don't rely on getting screen co-ords, they can be changed to getBoundingClientRect() easily enough, else they'll have to wait for bug 340571.

Comment 2

[Dion Sole]

(In reply to comment #1)
> 
> Similarly, lots of the JS stuff used getBoundingBoxFor(), and they'll no longer
> work in 3.5. If they don't rely on getting screen co-ords, they can be changed
> to getBoundingClientRect() easily enough, else they'll have to wait for bug
> 340571.
Er, bug 486200 that is...

Comment 3

[Dion Sole]

nsFocusController::MoveFocus() has been moved to nsIFocusManager::MoveFocus, so nsXFormsSwitchElement::SetFocus() and nsXFormsControlStub::HandleDefault() fail.

An easy find/replace for this one it seems.

Comment 4

[Dion Sole]

nsXFormsDOMEvent now fails because a number of nsIPrivateDOMEvent methods have (far as I can tell) vanished: SetCurrentTarget(), SetOriginalTarget() and HasOriginalTarget().

GetPreventDefault() has also moved from nsIDOMEvent to nsIDOMNSEvent, so it needs implementing in nsXFormsDOMEvent now.

And with all the above changed, it compiles correctly. But, it bails when trying to actually link and create xforms.dll, complaining about nsFocusManager::sInstance being an unresolved external symbol.
I'm not sure if that's due to my c++ noobieness or something else though...

Comment 5

[alexander :surkov (:asurkov)]

WIP patch would be nice

Comment 6

[Philipp Wagner [:imphil]]

Dion: that's all for mozilla-central, not mozilla-1.9.1 I assume?

Comment 7

[Dion Sole]

(In reply to comment #6)
> Dion: that's all for mozilla-central, not mozilla-1.9.1 I assume?
Yep.
So mozilla-central is going to be whatever ends up as firefox 3.6 then?
If so, you can ignore all of this stuff, since it's not gonna be relevant.

Looks like I didn't quite understand how the branching stuff worked -_-

Comment 8

[Philipp Wagner [:imphil]]

Exactly. Firefox 3.5 (Gecko 1.9.1) has much less changes to the core codebase (Mozilla2 is still a bit further away) ;)

Comment 9

[Dion Sole]

(In reply to comment #8)
> Exactly. Firefox 3.5 (Gecko 1.9.1) has much less changes to the core codebase
> (Mozilla2 is still a bit further away) ;)

Ah I see.
Well, guess this can be marked invalid then, and I have a new branch to check out.

Thanks.

Comment 10

[aaronr]

This bug isn't invalid at all.  If we want to support FF 3.6 in the future, then we'll have to make all of these changes.  If you don't care to finish up the work since it is a bit in the future, that is fine.  But please attach a patch for your work so far so that it can be finished up once we get to FF 3.6 support.  Thanks.

Comment 11

[aaronr]

changing title to 3.6 build issues

Comment 12

[Philipp Wagner [:imphil]]

Dion, have you a (work in progress) patch for the Gecko 1.9.2 (Firefox 3.6) build issues? It doesn't matter if it's not finished, I'll have a look at it then.