lewisje / svgweb

Automatically exported from code.google.com/p/svgweb
Other
0 stars 0 forks source link

Sputnik webpage not rendering correctly due to IE 9/XPath issue #559

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago
Compatibility issue with IE9 is occurring. The problem with svgweb is that they 
assume that you have xpath support if you have svg support, which happened to 
be true before but which is not true for IE9.

Sputnik uses Google js libraries – Closure, which is large and has 
many parts, and SVGWeb.  While Google or Sputnik fixed the copy of 
these libraries that Sputnik uses, any other site that uses the 
> libraries is still broken.  The libraries themselves need to be fixed.
> This specific bug is in svgweb - http://code.google.com/p/svgweb/.  

Notes from our Dev:
>
> The break seems to be caused by the goog.graphics.vmlGetElement_() 
> function (closure_sputnik_prettify_svg.js:5253).  It doesn’t seem to 
> expect that the element being requested might not be in a markup.  
> When the code is modified to the following, the problem goes away, and 
Sputnik can again execute:
>
>
>
> goog.graphics.vmlGetElement_ = function() {
>
>     if ( !this.element_ )
>
>         this.element_ = this.getGraphics().getVmlElement(this.id_);
>
>     return this.element_
>
> };
>
>
>
> Simply swapping the order of the operations on either side of the || 
> in the original return statement didn’t seem to solve the problem for 
> me.  When this change is made, however, the page still seems to have a 
> few visual issues. The way we get to this code without having placed 
> an element in the document is via the drawPath() function (line 5580).  
> createFullSizeElement is called to create a ‘shape’, it has an 
> attribute set, and then it is passed to a VmlPathElement, where a 
> getElementById call is eventually made (line 5420).
>
>
>
> When we switched the UA to that of Chrome (or Opera, or…), it took a 
> different code path to set up the page’s initial layout, one which 
> didn’t use VML and/or call the above function in the same capacity.  
> When using the Chrome UA, the call in decorate() (line 3881) to 
> decorateInternal goes to goog.ui.CssRoundedPanel.decorateInternal 
> (line 5715), while the IE UA calls 
> goog.ui.GraphicsRoundedPanel.decorateInternal (line 5767).  If we call 
> CssRoundedPanel.decorateInternal, we avoid the mess with the VML code, 
> and the page display looks correct too.  The decision of which to take 
> is decided in goog.ui.RoundedPanel.create (line 5657), and the 
> decision is purely browser-based and not feature-based.  We see when 
> the Chrome/Opera UAs are applied that we can handle this code path, it’s 
just that the browser detection doesn’t let us get there without cheating.

Original issue reported on code.google.com by vineetsa...@gmail.com on 14 Oct 2010 at 9:18

GoogleCodeExporter commented 8 years ago
Depends on issue 573 being fixed.

Original comment by bradneub...@gmail.com on 16 Nov 2010 at 10:04

GoogleCodeExporter commented 8 years ago
This is still happening for me. I'm currently forcing IE9 to use flash to avoid 
hitting this JS error

<code>

<!--[if gte IE 9]>
<meta name="svg.render.forceflash" content="true" />
<![endif]-->

</code>

Original comment by kuahy...@gmail.com on 23 May 2011 at 4:06