279027 - xforms.css doesn't work in trunk builds

Status: RESOLVED WORKSFORME

(Core Graveyard :: XForms, defect)

Description

[Olli Pettay [:smaug][[e-mail]] (holiday -> Aug30)]

Just try to use the following xforms.css in trunk builds.
The background is not set to red. Works on branch.

@namespace url(http://www.w3.org/2002/xforms);
repeat,
repeatitem,
contextcontainer,
group,
switch,
case {
  display: block;
  background: red !important;
}

Comment 1

[Allan Beaufour]

(In reply to comment #0)
> Just try to use the following xforms.css in trunk builds.
> The background is not set to red. Works on branch.

It does not work if you set the style directly in the XHTML page either, so the
bug must be hidden somewhere deeper. Not annoying at all, if one is looking at
repeats for the moment ....argh :(

Comment 2

[Allan Beaufour]

The elements seem to end up in the XHTML namespace instead, just forget the
XForms namespace and it works.

Could be bug 103225? It sets everything that is nsIContent::eHTML into the XHTML
namespace.

Comment 3

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Uh? Does xforms return true for IsContentOfType(eHTML)? Why? This will most
likly lead to crashes since we assume that only nsGenericHTMLElement does that.
See
http://lxr.mozilla.org/mozilla/source/content/html/content/src/nsGenericHTMLElement.h#86

Comment 4

[Boris Zbarsky [:bzbarsky]]

So could someone who knows how XForms is set up explain what the general deal is
here?  I know you guys use anonymous XHTML elements, but those should be in the
XHTML namespace anyway, right?  I don't see any IsContentOfType implementations
in the XForms module....

Comment 5

[Allan Beaufour]

(In reply to comment #4)
> So could someone who knows how XForms is set up explain what the general deal is
> here?  I know you guys use anonymous XHTML elements, but those should be in the
> XHTML namespace anyway, right?  I don't see any IsContentOfType implementations
> in the XForms module....

Yes, the anonymous content is XHTML, but the XTF-elements themselves are created
in the XForms-namespace (in the page), and repeat, repeatitem, etc are the XTF
elements.

Comment 6

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

I'm not familiar with how XTF works, but in XBL the anonymous content is styled
as a separate entitiy. So the wrapping element is styled according to its name
and namespace and the anonymous content is styled according to its.

What I don't understand is how the patch in bug 103225 could have changed
anything. The element that IsContentOfType is now called is before returned the
XHTML namespace anyway, not the XForms namespace.

Comment 7

[Boris Zbarsky [:bzbarsky]]

So can someone familiar with XForms:

1)  Attach a testcase showing the problem
2)  Estimate when this regressed?

Comment 8

[aaronr]

Attachment: test xforms.css

This .css should cause xforms testcases with groups, etc. to show red borders. 
It doesn't.

Comment 9

[aaronr]

Attachment: xforms group testcase

group testcase that, when loaded, should show the input field surrounded by a
red box

Comment 10

[aaronr]

The FREAKIEST thing is that when I build and run with my XForms XPath extensions
patch, I DO see the red box.  But my patch doesn't affect any of the limited
xpath that is in this testcase.  Timing bug?

I also noticed last week that with my xpath patch, external instance data is
loading, too.  And the problem there was that without the xpath patch, our load
handler was never getting callback for load finish of the external document. 
Something crazy going on!  Must be the magical incantations I say over my xpath
patch :=)

Comment 11

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

How are you guys binding xforms.css to the document? comment 1 seems to indicate
that this happens even for inline stylesheets. Is that true?

If so, could you create a very simple testcase with just two or three elements
and an inline stylesheet.

Comment 12

[Allan Beaufour]

Hmmm, did this sort of just fix itself?

Comment 13

[Allan Beaufour]

(In reply to comment #12)
> Hmmm, did this sort of just fix itself?

I would like to have an answer to why we had problems, but it works does it not?
... "works for me".