570401 - fancy DOM error display dumping on svg content.

Status: RESOLVED INVALID

(Firefox :: General, defect)

Description

[ffux]

User-Agent:       Opera/9.80 (X11; Linux i686; U; en) Presto/2.5.24 Version/10.53
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2) Gecko/20100212

<tr align="center" height="95%">
An html page , including some js, starts with a table. This first visible element is an embedded svgz.

	<td>
          <embed width="600" height="480" src="data_images/200tank-monitor.svgz" type="image/svg+xml" onload="svgloaded(event);" name="svg" id="svg">&nbsp;
	</td>
</tr>


A js function communicates with the server and receives a 403 string in responseText. This is correctly displayed in another control on the page by the sscript. However, FF then decides to display this error to the user by replacing the INNER content of the embedded element. This then seems to trigger some more DOM fancy work in FF and it displays a "content encoding error" and a retry button. 

It would seem the content encoding error is entirely the fault of FF messing with the page and putting html into an embedded object. 

Pressing retry reloads the svg content which is still there and valid. 


function display_response() {                                                                 
   if (xmlhttp.readyState==4) {                                                               
//     alert(xmlhttp.responseText);                                                           
     refresh_svg()                                                                            
     document.forms[0].elements['resp'].value=xmlhttp.responseText                            
   }                                                                                          
}                                                                                             
                                                                                              
                                                                                              
function callplot() {                                                                         
  if (delay)                                                                                  
    url="/cgi-bin/post.cgi?fn="+delay;                                                        
  else                                                                                        
    url="/cgi-bin/post.cgi?fn=*.gnu";                                                         
  xmlhttp.open("GET",url,true);                                                               
  xmlhttp.onreadystatechange=display_response;                                                
  xmlhttp.setRequestHeader('Accept','message/x-jl-formresult')                                
  xmlhttp.send(null)                                                                          
  return false;                                                                               
}                                                                                             
              

Reproducible: Always

Steps to Reproduce:
1.embed a non html object (possibly to be the first visible elememt)
2.trigger a 403
3.
Actual Results:  
valid svg contents removed. 
presumed attempt to insert a 403 error message
non svg inserted into svg object triggers more DOM magic that then whines about the mess it made.


Expected Results:  
Don't blow out the SVG graphic. 

Insert a message in an appropriate way in an appropriate format.

Inspect element menu option shows the heirarchy with inserted DOM code in place of the svg graphic code INSIDE the <embed></embed>.

It has totally replaced the svg content despite the embed still defining type="image/svg+xml"

Messing around inside an emdedded object is almost certainly going to screw up. This would seem a fundementally bad place to try to disply the 403.

I will open a second bug about why it even did that for this error which does not appear linked to an attempt to load the svg.

Comment 1

[ffux]

Also the deformed avg object does not reload despite still having src= correctly defined.

svgobj=document.embeds[0].getSVGDocument();

...

svgobj.location.reload(true)

Comment 2

[Robert Longson [:longsonr]]

Could you post a link to an online testcase please?

Comment 3

[ffux]

Sorry , can't do that. This a LAN instrumentation context, not public. Also the cause of the 403 error condition had to be corrected directly.

However , I'm looking into it with wireshark and it maybe the server , lighttpd, claiming to send compressed data when it isn't doing. 

I'll post back when I have something definite.

Comment 4

[ffux]

OK , I have a better understanding of what is happening. The server has to add an attitional header when serving up svgz content in order to get FF to handle it correctly. This is also being applies to the 403 response headers leading to invalid packages. In this sense it is a lighttpd problem.

However, this header tweek is simply a workaround for the fact that FF does not know how to handle svgz and had to be conned into treating it as an svg file that is compressed for transmission.

It would seem best is FF recognised svgz as a separate format and handled it correctly. What do you think?

Maybe that needs a separate bug now.

Comment 5

[Robert Longson [:longsonr]]

You must mark compressed data as compressed. We won't be writing code to detect file extensions.

Comment 6

[ffux]

file extensions suck, I'm not advocating that. 
The relevant bug for this issue is here:
http://bugzilla.mozilla.org/show_bug.cgi?id=308153

Apologies for incorrectly identifying the problem.

Comment 7

[Robert Longson [:longsonr]]

That bug is the same thing it basically says if you see a file extension .svgz then assume the content encoding is gzip. It's open as Tech Evangelism meaning that someone is or was trying to contact Adobe to get them to fix their servers it's not valid as a Firefox bug.