Application fails in FF4 due to setting a property on DOM node of "hidden"




8 years ago
8 years ago


(Reporter: nemo, Unassigned)



Firefox Tracking Flags

(Not tracked)





8 years ago was a page I made quite a few years ago just to muck about w/ unicode, which I'd just discovered had all those nifty glyphs (kinda like chess.xhtml in that same dir).

Recently, I accessed that file in FF4b nightly and noticed that it was no longer rendering all the table cells as it does in FF3.6 and other browsers.

Tentatively going with a regression although I'm not sure what the cause is since this is admittedly not a reduced page.

Hoping someone could say at a glance what happened.  Could it be because I used a table?  I thought it'd be cute to render a small deck of cards for browsers if javascript was not enabled.

Filing this in the wrong product due to a recently added (past year?) flaw in Bugzilla's bug reporting template when using a non-javascript browser. My apologies. Hopefully it'll be eventually fixed.


8 years ago
Assignee: administration → nobody
Component: Administration → General
Product: Bugzilla → Firefox
QA Contact: default-qa → general
Version: unspecified → Trunk
Is it valid to set the "hidden" attribute on a DOM node?  That's not a real attribute IIRC.  Since it's XHTML, we're probably rejecting it as invalid.

At least, the hidden attribute doesn't show up in Firebug, but it does show up in Chrome.

Comment 2

8 years ago
Those attributes are just added to the DOM node in javascript.  Nothing illegal about that.
deck[i].hidden = false;
They are not part of the actual XML when Firefox parses the page.
If you can make a minimized testcase, it might make it clearer what's going on.

Comment 4

8 years ago
Ok, I think I hit on the key difference, half-way through reducing...   Different in FF4 vs FF3.6  Same in FF4 and FF3.6

The issue seems to be my use of "hidden"

Apparently that triggers something in FF4 - presumably it is now some DOM node attribute.

The odd thing is it is only FF4 specific - some implementation of (X)HTML5 bleeding into XHTML 1.1?

Less sure if it is a bug now.  Although Safari and Chrome do work fine. is the original "app" (and I use the term loosely for this evening of long ago of hacking about) with .hidden replaced with .XYZZY - works in FF4.
Summary: Some table cells do not render in latest FF4b nightlies. They do in FF3.6 or older and other browsers. → Application fails in FF4 due to setting a property on DOM node of "hidden"
Smaug, do you know if this is intentional?
Blocks: 567663

Comment 7

8 years ago
Ah. Perhaps.  Well, the FF4 behaviour is a bit inconsistent then, since you'd think any "flipped" card (one without the face showing) would be invisible in FF4 since hidden would be true.

Certainly understandable it being honoured in older versions of HTML - heck. You don't ignore <canvas> just because it is HTML5 only...
I don't understand the previous comment.

.hidden is defined by HTML5 to work as follows:

myElement.hidden = true;

should make the element no longer be displayed (act as if .style.display is set to "none").

myElement.hidden = false;

should make the element act as normal (though of course can be overridden using CSS in all the usual fashions).

Is that now how FF4 nightlies behave? .hidden was not implemented in earlier versions of Firefox, so was ignored there.

Comment 9

8 years ago
The inconsistency seems to be that some elements are not actually hidden when that is toggled.

I was using a property I had called .hidden to show/hide the text.
If you click on the diagonal row of cards, the text is shown/hidden, yet the card does not vanish.

I'm not sure why that is, but it does seem inconsistent to me.
A minimized testcase would be great.

It seems like you are setting .hidden on <td> elements. Note that this would result in that <td> being removed, but the <td> next to it taking its place.
Nemo, what's the story on a testcase here?

Comment 12

8 years ago
Haven't started yet. probably not a big deal anyway. feel free to close it, I can alway reopen or refile if I confirm a real minified testcase for the problem mentioned in comment #9.
Sounds good. Reopening is definitely an option.
Last Resolved: 8 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.