349695 - login field does not appear (content of iframe is below visible area)

Status: VERIFIED FIXED

(Core :: Layout: Tables, defect, P1)

Description

[ryan bartlett]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1b2) Gecko/20060817 Camino/1.0+
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1b2) Gecko/20060817 Camino/1.0+

On the AmSouth homepage, the login field for your account does not appear, the area remains blank.  Works fine on explorer and Safari.

Reproducible: Always

Steps to Reproduce:
1.Go to amsouth.com
2.
3.

Comment 1

[froodian (Ian Leue)]

I see this.  Work in Bon Echo, also broken in CocoaFox.

Comment 2

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

This is bizarre.

Here's the deal, in layman's terms: the iframe that contains the login field is quite tall in Camino for some reason (with the content all the way at the bottom); in other browsers, the iframe is the size of the content.  So when the iframe loads into the appropriately-sized table cell, we see the "top" of the iframe, which is some blank space (thus we really see the bgcolor of the table containing the iframe).

josh/mento/pink/smfr/wevah: any idea why we're getting this extra blank space above the content in the iframe <https://ibank.amsouth.com/tether/ibanklogon.asp> in (apparently) Cocoa widgets?

Ryan, you can access the form until this bug is fixed by clicking on where it should be and using the down-arrow key to bring it into view....

Comment 3

[Simon Fraser [no longer active]]

The page looks fine to me (Version 2006042704 (1.0.1))

Comment 4

[philippe (part-time)]

I see the same problem with A BonEcho build dated 20060817.
This is actually a (recent) regression.
The form tag is incorrectly nested: <table><form><table>......

I'll attached the sightly modified source code to show the issue.

Hmm I think Boris Z recently worked on some code about this.

Comment 5

[philippe (part-time)]

Attachment: test case

The parent table is shown with a thick red border. Look how the child table is dropped below the parent table.

Comment 6

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Ah, thanks for that tip, philippe!  I saw this in my proto-1.0.3 build and 1.0+ so I assumed this was Cocoa, but like Simon on 1.0.1, I don't see this when I check 1.0.2.

Comment 7

[philippe (part-time)]

Works correctly on Bon Echo
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1b1) Gecko/20060817 BonEcho/2.0b1 
Fails
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1b2) Gecko/20060818 BonEcho/2.0b2

My suspicion is on bug 348455, adding Boris to the cc

Comment 8

[Boris Zbarsky [:bzbarsky]]

Yes, this is a regression from bug 348455 (or rather from bug 285727).  The problem is that we left the "quirk" (which we also do in standards mode) only for cases when the page doesn't explicitly style the form's display.... and this page does:

  form { display: inline; }

So either we accept this regression in this very rare case or we need to change the patch for bug 285727.  See bug 285727 comment 21.

Perhaps what we should really do here is use a post-resolve callback....  This seems like the sort of icky case where it could be appropriate.  David, would you be OK with that?

Comment 9

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Why can't we just back that out and use a rule in the UA stylesheet like:

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

?

Comment 10

[Boris Zbarsky [:bzbarsky]]

*** Bug 349922 has been marked as a duplicate of this bug. ***

Comment 11

[Boris Zbarsky [:bzbarsky]]

Because  that will affect XHTML as well, which seems undesirable (given the !important).

Comment 12

[Daniel Veditz [:dveditz]]

Sounded like dbaron maybe had ideas on how to fix this, maybe this should go to bz instead, but either way an unowned blocking regression is not good.

Comment 13

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I suppose a post-resolve callback is acceptable.  We should really have a way of distinguishing HTML and XHTML, though...

Comment 14

[Boris Zbarsky [:bzbarsky]]

We could just create a :-moz-is-html pseudo-class or something.

Comment 15

[Boris Zbarsky [:bzbarsky]]

Attachment: One possible approach

The other option is to have a stylesheet that only applies to HTML documents (much like quirks.css only applies to quirks documents).  That might be a better approach...

Comment 16

[Daniel Veditz [:dveditz]]

Is this likely to get reviews+baking enough to make 1.8.0.7? Not looking good if this weekend is the code freeze.

Comment 17

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Comment on attachment 235321 [details] [diff] [review]
One possible approach

r+sr=dbaron.  (I'm assuming the nsHTMLStyleSheet changes are a cvs-generated backout; I didn't look at them very closely.)

This should be pretty low risk.

Comment 18

[Boris Zbarsky [:bzbarsky]]

Fixed on trunk.

Comment 19

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 235321 [details] [diff] [review]
One possible approach

I think this should be pretty safe for branch.

Comment 20

[Daniel Veditz [:dveditz]]

Comment on attachment 235321 [details] [diff] [review]
One possible approach

Thanks for responding re:risk
approved for the 1.8.0 branch, a=dveditz for drivers

Comment 21

[Boris Zbarsky [:bzbarsky]]

Attachment: Merged to 1.8.0 branch

Comment 22

[Boris Zbarsky [:bzbarsky]]

Fixed on 1.8.0 branch.

Comment 23

[Mike Schroepfer]

Comment on attachment 235321 [details] [diff] [review]
One possible approach

a=schrep approving all previously triaged patches which were baking on trunk.

Comment 24

[Boris Zbarsky [:bzbarsky]]

Fixed on 1.8 branch.

Comment 25

[Carsten Book [:Tomcat]]

Verfied fixed for 1.8.0.7 with Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.0.7) Gecko/20060906 Firefox/1.5.0.7 and verified fixed for 1.8.1 with Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.1b2) Gecko/20060821 Firefox/2.0b2

Comment 26

[Boris Zbarsky [:bzbarsky]]

Checked in a testcase for this.

Comment 27

[Hixie (not reading bugmail)]

Is the !important needed?

Comment 28

[Boris Zbarsky [:bzbarsky]]

Yes, if you want to fix this bug, because if it's not !important then the page's use of "form { display: inline }" (which is what the site was doing; see comment 8) will override the UA style.