We've recently started using Polymer at work and we like it but we've found that the ShadowDOM polyfill causes serious performance issues in Firefox when used in combination with heavyweight DOM manipulation (we've encountered the issue with the DataTables jQuery plugin but the effect can also be seen by simply having Firebug open).
We can live without that polyfill so we decided to just use the CustomElements and HTMLImports ones. We followed the official guide on building individual polyfills and generated the minified JS files but when we use them both we consistently get this error:
"TypeError: CustomElements.parser is undefined"
When we use platform.js we do not get this error. I've even tried generating older versions of the polyfills to see if it is a recent issue to no avail.
When we dug into the code it seems the bootstrap function of CustomElements is calling CustomElements.parser.parse() - parser is added to CustomElements shortly before but between these two things something is resetting CustomElements and it loses its parser.
I've managed to replicate the problem in a small test case. I can't put it on JSFiddle as it requires HTML imports and I got CORS errors so I've had to host it on my shared server (please be gentle!). You will need to open it in Firefox to see the error (you also see the error in Chrome but it doesn't need the polyfill so the custom element still shows up):
http://lilchef.co.uk/polymer-polyfill-bug.html
By comparison here is the exact same test case but using platform.js instead. This works but includes the problematic ShadowDOM polyfill (if you open Firebug whilst running it you should experience the slowdown):
http://lilchef.co.uk/polymer-polyfill-platform.html
We should be able to use these two polyfills without having to use ShadowDOM shouldn't we? Has anyone else encountered this issue?
Related
My company works with POS and we're using a custom browser based on Chrome (webkit) with a few (minor) changes in its behavior.
We're creating automated tests with Selenium using Chrome, but now it's time to move to the custom browser instead.
How to proceed? I see many questions related to custom capabilities, but none related to custom browsers.
You didn't specify details on programing language, what exception you got from setting Chrome binary to your custom browser, etc... So I'll make some assumptions.
First of all, from my experience it's achievable, but I can't remember the exact details, except that we had some versioning issue that we needed to comply with on our custom browser.
However, my suggestion to you is to clone Selenium and create a new ChromeDriver() with your cloned project in debug mode, and see where it fails, then look for the specific solution, and continue from there.
I have developed working D3 driven charts and as far as all the other browsers go, there are no problems.
but recently the need to support them also in Internet Explorer 8 cropped up.
But so far i can't make this html display in IE8.
these are the tags used in D3:
<svg> <path> <g> <line> <circle> <rect>
for the last 6 hours i have skimmed through a lot of materials and questions including:
"Display inline SVG in IE8" which has this answer from October 2012:
I have been looking into this too and a number of options came up.
Chrome Frame - A browser plug-in that actually uses chrome underneath, meaning SVG just works. This is great if you're able to deploy plugins to the browser, for a real commercial environment however this may not be possible.
SVG Web - The aim is it bring SVG to all browsers. It looks like a fairly large project, one that's had Google's input. This doesn't however work out of the box with D3 though I don't know much about the issues.
D34Raphael - You've mentioned this one, I found again it doesn't work out of the box. Check the project out on GitHub, there hasn't been any commit activity in months and there's some pull requests "first pass on trying to get support for .on() required for event binding". If it doesn't support events, is that an issue to you? I'd generally keep away from this one.
R2D3 - Again another one you mentioned. I took the Sankey example from the D3 website and had to make a few changes to get it working. The main things I couldn't get working (Drag Events, Groups - though can use an alternative). It took about a day of effort to get the example working in IE8 and I believe is in a useable state. The project on GitHub is also much more active, the developer is committing, pulling work in and is very active on discussions etc. This gets my vote.
Also:
D3 IE8 Compatibility?
wikipedia.org/wiki/Scalable_Vector_Graphics
SVG Web Compatibility
But the solutions using client-side plugins are not acceptable and so far it looks that i can't display svg in IE8.
So the solution is to find some other ways to render vector graphs.
I presume that others have had the same problems
Edit:
either way, people that will encounter this same problem after me will at least have somewhat concentrated materials and will realize that there is no easy/real solution to display svg on IE8 and better to spend time starting on the existing code rewriting/adjusting for non-svg version
Edit:
after some testing i would say that its worth trying to go through R2D3 examples and see if its possible to simplify/execute the code in IE8
Samples
Edit:
During the process of testing different elements separately some r2d3 problems seem to arise
most common would be Invalid argument and Object doesn't support this property or method
as i am not used to develop for IE8 there were some useful tips that i found:
dump javascript vars
and
display objects
Not sure if you are still looking for an answer, but I ran into this issue on a project a few years back. We ended up switching over to HighCharts for the browser compatibility. At the time it was still in its infancy as a charting library, since then it's become much more powerful and still maintains browser support back to IE6.
Unfortunately for most people now supporting IE8 its down to client restrictions rather than consumers.
Without informing those that have requested it of the restraints, backwards compatibility and cost implications along with valued links from this post, the solutions for making canvas work in IE7/8 and using the JScharts variants is your best option.
Of course, it means not using D3 unless you want to double your work load = cost. Just remember to mention that every time.
Good luck
IE8 (as far as I can see) simply doesn't support SVG. The only solution I can see working is using a different graph library which uses a canvas to draw it's components. Think of libraries like CanvasJS, ChartsJS, GoJS or VisJS Network Graphs and then using excanvas to make them work for IE8.
Another solution I found when researching this topic is using Chrome Frame. It makes IE8 support SVG. Though, sadly, Chrome Frame is retired and no longer supported anymore.
Knowing all this you have to ask yourself: "Is it worth going through all of this for the less than 0,1% of people who still use IE8 and below?".
Because, if you want complete d3 compatibility you probably would have to write your own converter from svg to canvas and even then, you still have to hope that excanvas supports all the canvas functions you write.
Edit: Changed browser percentage to current IE8 usage
I stumbled across a weird issue when testing an application on an old chrome version (5.0.3).
So basically I'm using a controller on a directive like:
<div ng-controller="MyController" class="my-directive-with-isolated-scope">
<!-- ... -->
</div>
This seems to be perfectly valid in most recent browsers, however it throws an exception in older versions of Chrome:
Multiple directives [myDirectiveWithIsolatedScope, ngController] asking for isolated scope on:…
Any idea why there's a difference?
[Edit]: Just noticed that this also applies to Firefox.
I would probably say that having a controller directive and another directive sharing an element may be problematic. In this case, you are saying I want each directive to have an isolated scope on the same element. What is your directives purpose? If you moved your directive to a sub element then the problem would go away. Of course this may not answering your question.
Assuming I already have valid code, is there a tool or plugin that I can use to evaluate my website code and highlight areas where different browsers could potentially display the code differently? I am aware of websites like browsershots and I have VMs to test, but I'm wondering if there is something to shortcut the process by looking at the code and warning of well known cross-browser compatibility red flags.
For example, when using CSS which is not universally supported yet. The following is valid CSS 2.1:
display: run-in;
Validators which are aware of CSS 2.1 will pass it with flying colors, but really, a red flag should be thrown, indicating that it does not work in Firefox 3. On the other hand,
border-radius: 10px;
is actually pretty well supported in updated browsers, even though it is CSS3.
This is new in Javascript, but is also passed by validators:
getElementsByClassName();
but it would be better if a warning popped up notifying me it won't work in IE8.
Another example is well known rendering bugs, which can be triggered by weird (valid) situations. I understand there is no replacement for opening up the website in every single browser on every system to really see how it works, but I am just wondering if there is some tool that can help check that I'm writing interoperable code as I go, so that I can test more frequently in the development process and spend less time working out bugs later.
Unfortunately, the answer is no.
I once started looking into creating a tool exactly as you describe. The reality is that most libraries like jQuery actually make use of browser incompatibilities and different interpretations of standards (or ignoring the standards).
So, if you're using any of the standard libraries then you'd receive tons of warnings and actually get very little out of it. The amount of spam simply will shadow the actual bug you might have introduced.
What matters more is whether the incompatibilty actually affects the end result. Hence we went for what-you-see-is-what-you-test method instead of static code analysis.
I was working on a site some months ago and I used mootools menumatic from one of the resources sites from the internet.Firefox 4 was still beta at that time and I didnt tested my menu in it and currently i tested in firefox 4 and amazingly the script didnt work.where might be the problem.Thanks in advance.enter link description here
you use mootools 1.2.0 - just so we are clear on a few things here, and I am repeating myself but there you go...
mootools 1.2.0 is now 3 years old - http://ajaxian.com/archives/mootools-12-released - june 13th 2008. at the time of release, firefox 4 was not even a design concept.
mootools 1.2 relied on feature detection - read the previous thread linked above - and on the now deprecated getBoxObjectFor to determine if you were in a gecko-based browser like FireFox. Running this small test in FF4 on your site:
(via the firebug console):
JSON.encode(Browser.Engine);
"{"name":"unknown","version":"","unknown":true}"
Bottom line is, the menu works but it creates a javascript exception when trying to use specific style setters/getters that will fail due to the framework not understanding the browser version. This is likely NOT going to be the only error but you will need to write some extensive tests to catch all problems as many may result in different/undesired functionality rather than outright exceptions.
In short, the answer you may not want to hear: upgrade your mootools to AT LEAST 1.2.5.1 or ideally, 1.3.2 - you may need to use the compatibility mode version so your old plugins continue to work.
Other breaking changes: Function.bind used to take args of bindObj, [args] and is now natively defined as bindObj, arg1,... argn
And finally, you may want to accept some answers, 50% is way too low