Closed Bug 47449 Opened 24 years ago Closed 24 years ago

Mail2web site confuses mozilla, bad display etc

Categories

(Core :: DOM: HTML Parser, defect, P3)

Product:
Core
Component:
DOM: HTML Parser
Platform:
x86
Windows NT
Type:
defect

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: schendel, Assigned: pollmann)

References

(
URL
)

Details

(Keywords: testcase) 

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; m18) Gecko/20000802
BuildID:    2000080208

www.mail2web.com.  Enter a valid pop3 mail account and "check mail".
(at least) 3 problems:
1. Mark an email for deletion and select the LOWER "delete" button.
Mail2web thinks you said "delete all".  The UPPER delete button is OK.
2. Mark an email for deletion and select the upper delete button.
In the new page, notice that the left pane now offers to retrieve the
latest "0" messages instead of the 10 or 20 you selected, and in fact
this is what it does.  :(
3. Click on an email to read it.  Click "reply".  The text entry area
is now in centered mode instead of normal left-align.

I tried to View Page Source to see what was going on, but apparently
mail2web is doing something goofy and the results aren't particularly
informative. (to me.)

Reproducible: Always

Reproducible with various PC and Mac (MacOS 8.6) builds back at least
as far as M15.  I kept waiting for someone else to notice but ... :)
#3 may have been bug 43420.


I'm unwilling to enter my POP account and password into this page.  Anyone else
willing to test and possibly testcase this bug.
Keywords: qawanted
Surely a temporary email address could be set up for testing.  If all else

fails you could set up a temporary Earthlink or similar account, which includes

a pop3 email service.


In my infinite boredom, I sacrifice the confidentiality of my email address to
bring you this intelligence ;)

I'm using mozilla m17 of the missing build ID, and netscape 4.74. The first 2
issues are a result of two <form> tags crashing into each other, so first and
foremost it is the authors of the page that are retarded, and in sumarry,
mozilla's handling of this is right and all it's browser buddies are wrong.
Anyway, I'll show you what happens. For each problem I'll show some related html
code and a sniffing of netscape 4's and mozilla's resultant form postage. Observe

#1
<HTML>
<BODY>
<FORM METHOD="POST" ACTION="http://www.microsoft.com/hi.cgi">
<FORM METHOD="GET" ACTION="http://www.microsoft.com/hi.cgi">
<INPUT TYPE="SUBMIT" NAME="submit" VALUE="Delete">
</BODY>
</HTML>

Mozilla puts the delete button under the second tag, netscape 4 puts it under
the first.
In the mail2web page, the top delete & delete all buttons come under the first
form tag, and the bottom buttons under the second tag. The first form tag
specifies a script that understands how to do both delete & delete all
operations, and the second form tag points to a script that only knows delete
all. So the bottom delete button does delete all.

Mozilla obviously has the right idea as far as guessing author intent goes (it's
alot easier to accidentally leave off a </form> than to accidentally add a new
<form> tag), so nothing to be done about this but flame mail2web's webmasters I
think

<mozillasniff>
GET /hi.cgi?submit=Delete HTTP/1.1
Host: www.microsoft.com
User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.16-3 i686; en-US; m17)
Gecko/20000807Accept: */*
Accept-Language: en
Accept-Encoding: gzip,deflate,compress,identity
Keep-Alive: 300
Connection: keep-alive

</mozillasniff>
<nutscrapesniff>
POST /hi.cgi HTTP/1.0
Connection: Keep-Alive
User-Agent: Mozilla/4.74 [en] (X11; U; Linux 2.2.16-3 i686)
Host: www.microsoft.com
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, image/png, */*
Accept-Encoding: gzip
Accept-Language: en
Accept-Charset: iso-8859-1,*,utf-8
Content-type: application/x-www-form-urlencoded
Content-length: 13

submit=Delete
</nutscrapesniff>

#2
<HTML>
<BODY>
<FORM METHOD="POST" ACTION="http://www.microsoft.com/hi.cgi">
<INPUT TYPE="SUBMIT" NAME="submit" VALUE="Delete">
<FORM METHOD="GET" ACTION="http://www.microsoft.com/hi.cgi">
<INPUT TYPE="HIDDEN" NAME="listperpage" VALUE="10">
</FORM>
</BODY>
</HTML>

Mozilla does not send the listperpage key back, but netscape 4 does.
Complaint #2 is caused by mail2web.com not receiving the listperpage key back.

Again, mozilla seems to have the right idea.

<mozillasniff>
POST /hi.cgi HTTP/1.1
Host: www.microsoft.com
User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.16-3 i686; en-US; m17)
Gecko/20000807Accept: */*
Accept-Language: en
Accept-Encoding: gzip,deflate,compress,identity
Keep-Alive: 300
Connection: keep-alive
Content-type: application/x-www-form-urlencoded
Content-Length: 13

submit=Delete
</mozillasniff>
<nutscrapesniff>
POST /hi.cgi HTTP/1.0
Connection: Keep-Alive
User-Agent: Mozilla/4.74 [en] (X11; U; Linux 2.2.16-3 i686)
Host: www.microsoft.com
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, image/png, */*
Accept-Encoding: gzip
Accept-Language: en
Accept-Charset: iso-8859-1,*,utf-8
Content-type: application/x-www-form-urlencoded
Content-length: 28

submit=Delete&listperpage=10
</nutscrapesniff>

#3 is the same issue as is being dealt with in bug 43420 aka bug 46987 (?)

+testcase, shunt to parser, is qa still wanted?
how come I don't have permissions for any of those things..

ah well, now for something else meaningless to do
finishing up.  hoshem@mel.comcen.com.au  you should now have permissions to edit
bugs.  email me if you run into any problems/questions.  Thanks for the
investigation.
Assignee: asa → rickg
Status: UNCONFIRMED → NEW
Component: Browser-General → Parser
Ever confirmed: true
Keywords: qawanted → testcase
QA Contact: doronr → janc
Pollmann: as far as I can tell, this isn't a parser bug. Can you make sense of 
it? Could it be a form posting issue?
Assignee: rickg → pollmann
<shameless plug>
Free IMAP/POP accounts can be obtained from www.myrealbox.com and
www.subdimension.com.  I've used both in the past.
</shameless plug>

I just tested this out.

1) is explained above.  The html of the website is flawed
2) ditto
3) As with the previously reported dups of this bug, this is now fixed in the
latest nightly builds - the textarea is left-aligned.

Marking WORKSFORME.

To test, feel free to use the temporary free POP account I created:

account:  moztest@myrealbox.com
password: password
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → WORKSFORME
updated qa contact.
QA Contact: janc → bsharma
QA Contact: bsharma → moied
You need to log in before you can comment on or make changes to this bug.