window.getComputedStyle for some forms erroneously marks display "none"

RESOLVED INVALID

Status

()

Core
DOM: CSS Object Model
RESOLVED INVALID
3 years ago
3 years ago

People

(Reporter: Jamie Phelps, Unassigned)

Tracking

40 Branch
x86
Mac OS X
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

3 years ago
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_3) AppleWebKit/600.5.17 (KHTML, like Gecko) Version/8.0.5 Safari/600.5.17

Steps to reproduce:

To Reproduce
---------------
Visit a site with a particular (as yet undifferentiated…) `<form>` construct. Two examples as of 2015-04-10 at 8:52 AM CDT:

https://services.actstudent.org/OA_HTML/actibeCAcdLogin.jsp?null
https://servicedeskn2.naismc.com/arsys/shared/login.jsp?/arsys/forms/narmdy2/CITS+Service+Desk/Support/

Open console and execute: `window.getComputedStyle(document.forms[0]).display`

Notes
------
- The problem does not occur on sites with more straightforward forms such as https://accounts.google.com/AddSession
- Tested in Firefox 37.0.1 and Firefox 40.0a1 (2015-04-10)
- Tried passing `null` and other valid pseudo-element strings to getComputedStyle with no change in results.


Actual results:

The display property is computed as "none"


Expected results:

The display property is computed as "block" as reported by Safari and Chrome on OS X.
(Reporter)

Comment 1

3 years ago
Here is another site that exhibits a mix of the two behaviors, display "none" and display "block":

https://www.myuhc.com/member/prewelcome.do?currentLanguageFromPreCheck=en

    Array.prototype.slice.call(document.forms).forEach(function(f) { console.log(f.id, window.getComputedStyle(f, null).display) });

Updated

3 years ago
Component: Untriaged → DOM: CSS Object Model
Product: Firefox → Core
Jamie, thank you for reporting this issue.

> https://services.actstudent.org/OA_HTML/actibeCAcdLogin.jsp?null

The form on this site has display:none set.  That's because of this rule in the UA stylesheet:

  :matches(table, thead, tbody, tfoot, tr) > form {  display: none !important; }

See the spec at https://html.spec.whatwg.org/multipage/rendering.html#tables-2 (though you have to scroll down a bit to find that rule).  In this case the <form> is a direct child of <table>.

> https://servicedeskn2.naismc.com/arsys/shared/login.jsp?/arsys/forms/narmdy2/CITS+Service+Desk/Support/

Again, <form> as direct child of <table>.

> The display property is computed as "block" as reported by Safari and Chrome on OS X.

Sounds like they're not following the spec.  Minimal testcase showing that they are not:

  data:text/html,<table><form><script>alert(getComputedStyle(document.forms[0]).display)</script>

They're doing _something_ bizarre, though, because if you do:

  data:text/html,<table><form style="border: 10px solid yellow">

the border doesn't show up, though for a display:block box it should, and does if the <table> there is removed.  And if you examine the getComputedStyle width or height of that form you get "auto" which per the spec for getComputedStyle is only possible if the element has no CSS box.  Again, per spec it _shouldn't_ have a CSS box, but for the simple reason that it's display:none.  It looks like Chrome and Safari are suppressing the box via some sort of magic behavior they're not mapping to CSS instead.

Please do report bugs to Chrome and Safari about their bizarre behavior here.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → INVALID
(Reporter)

Comment 3

3 years ago
Thanks for the detailed feedback. So, it sounds like it's not sufficient to say that if an ancestor of an element has `display: none;` that the element itself is not shown on screen. That's good information to know, but I'm not sure now how we can determine if a particular form is actually viewable on the screen… :\
> So, it sounds like it's not sufficient to say that if an ancestor of an element has
> `display: none;` that the element itself is not shown on screen.

Oh, it is.  But note that the <form> has no descendants in those testcases, in any browser.  It's an empty element.

> but I'm not sure now how we can determine if a particular form is actually viewable on
> the screen

Telling that something _is_ viewable is much harder.  It could be display:block but hidden behind something else, or inside a too-small overflow:hidden area, or opacity: 0, or visibility: hidden, etc.
(Reporter)

Comment 5

3 years ago
Curiouser and curiouser… I do see that the `<form>` is an empty element, but this has to be something the browser is doing. When I curl the login page, the markup looks different:

<form name = "userform" method="post" action="" onsubmit="return(UserFormSubmit());">
<tr>
<td align="right"><label style="font-weight:normal;" for="username">User ID</label></td>
<td>
<input type="text" name="username" id="username" size="12" maxlength="12" value="" tabindex="1">
&nbsp;<span class="small" style="font-weight:normal;"><a href="actibeCAcdUidAssist.jsp"  tabindex="7">Forgot User ID?</a></span>
</td>
</tr>
</form>

The form actually *isn't* empty, but somehow the user agents are rearranging the markup. Is this related to the table > form spec somehow?
> The form actually *isn't* empty, but somehow the user agents are rearranging the markup.

Yes, because the markup is invalid.  The fixup the parser performs in this case is clearly defined in the spec and leaves the form empty (but the form controls still associated with it).

This dates back to when display:contents did not exist, so the only way to get the right layout out of this stuff was to make sure the form didn't contain the misnested table internals and didn't generate a box at all.
You need to log in before you can comment on or make changes to this bug.