187494 - graphic image surrounding the login form is not displayed properly.

Status: RESOLVED WORKSFORME

(Core :: DOM: HTML Parser, defect)

Description

[kls]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3a) Gecko/20021212
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3a) Gecko/20021212

There are four gaps in this image.  That is, there are four short white bands,
one-third down and two-thirds down on both the left and right sides of the
image...  I wish I had the proper vocabulary to describe this better...  For
what is is worth, IE does display this image correctly.

I have no idea if this page is broken or coded wrong.... obviously this is not
very important, but I thought someone might want to see it...

Reproducible: Always

Steps to Reproduce:
1. go to http://mymail.hongkong.com/index_e.html
2.
3.

Actual Results:  
image not displayed properly

Expected Results:  
display image properly

Comment 1

[Ruslan Ismailov]

Such behaviour produce by a way to long input form for login :

<input maxlength="32" name="PASSWD" size="12" type="password">

(this long input move central table cell and doing a vertical "gap")

By uncertain for me reason type="password" should be first argument of <input>.

Comment 2

[Ruslan Ismailov]

Attachment: atributes of input before "type" ignored

This two input's differ only in argument's order.

Comment 3

[Ruslan Ismailov]

Oh, by the way. I think this bug component should be parser and severity critical

I found, that <BUTTON name="submit" value="submit" type="submit"> is brocken (it
is one of examples in http://www.w3.org/TR/html401/interact/forms.html). 

Comment 4

[Christian :Biesinger (don't email me, ping me on IRC)]

nothing to do with image graphics, this is *probably* Tech Evangelism, but I'm
not sure about this, therefore -> layout for triage

Comment 5

[Christian :Biesinger (don't email me, ping me on IRC)]

sorry - I didn't really read through this bug before changing component...

This is not Parser, because DOM Inspector correctly shows these attributes.  So
it's probably Form Controls, per comment 3, reassigning there.

Comment 6

[Hixie (not reading bugmail)]

This is parser, because the parser should be sending exactly the same output
whatever the order of the attributes.

Comment 7

[Ruslan Ismailov]

It is realy strange -- I could not understand why size="X" before type (all
others attributes is not affected by this -- I check it :-) is ignored. I think
that name of bug should be changed to "input size is not in use if placed before
type='something'".

Comment 8

[Boris Zbarsky [:bzbarsky]]

Hmm... Clearly saying early on that the attribute order matters would be
helpful... ;)

And Ian is wrong; this is not a parser bug (again, the DOM is correct; the
parser does exactly the same thing).  It's a bug in the DOM implementation.

*** This bug has been marked as a duplicate of 186325 ***

Comment 9

[kls]

First...

------- Additional Comment #8 From Boris Zbarsky  2003-01-02 17:09 -------

*** This bug has been marked as a duplicate of 186325 ***

And then...

------- Additional Comment #11 From Peter Van der Beken  2003-01-22 11:54 -------

This looks fixed to me, probably by the fix for bug 188872.

But Bug 187494 dosn't look fixed to me?  I am using 1.4a (Mozilla/5.0 (Windows;
U; Windows NT 5.0; en-US; rv:1.4a) Gecko/20030401) and the original site I
reported, http://mymail.hongkong.com/index_e.html, is still broken... Do I not
understand something???

Comment 10

[kls]

This bug is not yet resolved as of June 16, 2003, using Mozilla 1.4b. 

Comment 11

[Boris Zbarsky [:bzbarsky]]

The testcase in this bug worksforme, as does the page in the URL field... is
there still a problem here?

Comment 12

[Henri Sivonen (:hsivonen)]

The site is gone and the test case is WFM.