743222 - Bad html code is displaying in Screen

Status: RESOLVED INVALID

(Core :: DOM: HTML Parser, defect)

Description

[Gobinath]

Attachment: Errorscreen.bmp

User Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0.2) Gecko/20100101 Firefox/10.0.2
Build ID: 20120215223356

Steps to reproduce:

We are testing the ESS and MSS Applications with FIREFOX 10, which we have developed with SAP Environment.






Actual results:

When we opened the "Work Schedule" Application, it is showing with html code.which is not required.


Expected results:

It should not show that html code in that application.

Comment 1

[Matthias Versen [:Matti]]

That is very likely a html error that has to be fixed in the html. 
We need a testcase, either public URL or as attachment to proceed.

Comment 2

[Gobinath]

Attachment: Document for Testing

Comment 3

[Gobinath]

Attachment: Document for Testing

Comment 4

[Matthias Versen [:Matti]]

The hostname  https://magn54.pok.... doesn't resolve for me (address not found).
Maybe it's only reachable within the LAN ?

Comment 5

[Gobinath]

yes. That link is open only LAN. just for our info i have given that document.Please go thru the document, so that you can find where we are facing this problem. OR if you want have net meeting (if it is applicable), we can have it.

Please call me 9740776535, if you have any queries. OR you can give me your contact number. So that we can discuss and proceed further.

Comment 6

[Matthias Versen [:Matti]]

The issue is most likely a bug in the html source code of the page.
Could you save the page as html file and look if you can reproduce the issue with the saved page ?

Note: I'm a Mozilla community member doing the bug triage here. Calling from Germany to the US to discuss something is outside of my scope. With enough technical information like the page source I can only tell you if this is a bug in Firefox or not. In case of a bug in Firefox (not very likely IMO) i can move this bug forward to the right developer who will fix the bug. There is nothing that a developer or I can do without the page source or public testurl that shows the bug.

Comment 7

[Gobinath]

Herewith attached HTML file for that page source.

Comment 8

[Gobinath]

Attachment: HTML Source for Error page.

HTML source code for Error Page source

Comment 9

[Matthias Versen [:Matti]]

Please attach it as text-file instead of a pdf file.
It's not possible to copy text or search inside the pdf.

Comment 10

[Gobinath]

Attachment: HTML Code for page in Text Format

Herewith attached the HTML code in Text format as u requested.

Comment 11

[Rekha]

Attachment: Source code for the work schedule table

Hi,

Please find the html file attached which can be viewed with FF3.6 to FF11 to replicate the issue and IE to confirm that there is no issue. Kindly view the source code and let us know why unicode environment is not supported in FF. 

Regards,
Rekha M

Comment 12

[Matthias Versen [:Matti]]

I get the same issue with Opera11.6 but it works with IE9
This is very likely a bug in the html code and not a browser bug.

Comment 13

[Henri Sivonen (:hsivonen)]

(In reply to Rekha from comment #11)
> Please find the html file attached which can be viewed with FF3.6 to FF11 to
> replicate the issue and IE to confirm that there is no issue. 

The page doesn't work in IE10 (IE10 mode), either.

Also, Chrome and Safari show the same problem as Firefox and Opera.

> Kindly view
> the source code and let us know why unicode environment is not supported in
> FF. 

Unicode is supported in Firefox.

Please view attachment 628569 [details] in a hex editor. There are runs on zero-valued bytes (aka. '\0', aka. 0x00) all over the file. Previously, browsers threw away these bytes before parsing HTML. Nowadays, the zero bytes are not ignored in some locations in HTML source as a defense-in-depth measure, because putting bytes that get dropped in strategic positions within markup could help malicious markup invade naïve XSS filters. (Of course, it is better for sites to use non-naïve XSS filters, but nonetheless HTML5-compliant browsers err on the side of not ignoring bad bytes in cases where they could be used for tricking naïve filters.)

I'm resolving this as "INVALID" in the sense that the allegation of behavior is correct, but the behavior is by design (in compliance with the standard) and not a defect.

That the output of your application contains run of bytes with value zero all over the place suggests that there is a bug on the server side in the routines that handle the output stream from the application.