I have a very simple page that includes webcomponents-lite.js polyfill v1.1.1 and polymer.html v2.6.0. I open the page, served through polymer serve, in IE11 or Edge. When I open F12 tools, it takes up to several minutes until the tools are ready and responsive. This makes it extremely frustrating to debug IE compatibility issues. What is the cause? Can it be improved?
The same problem occurs in earlier versions of webcomponentsjs and polymer. Including webcomponentsjs alone does not seem to have the effect.
Related
I have a rather large Vue 3 application (~550 components). It takes two minutes just to run vue-cli-service serve and around 20 seconds to re-build it after each change. Hot reload stopped working a long time ago so it always needs to be refreshed in the browser even after a small style change. Moreover, the app is still not finished and it will probably get 2-3 times this big in the next year so it will probably be even worse.
Because of these problems, I've decided to migrate it from Vue CLI to Vite. I have already resolved a lot of problems and the app seems to work with Vite now with so much better loading times.
However, it sometimes gets stuck when I start a dev server (vite command) and open it in a browser. The page keeps loading and I can see a lot of pending requests in the Network tab of Chrome DevTools. There's nothing special in the output of vite --debug and running vite --force doesn't help either.
When this problem occurs, the browser always loads a lot of modules (~900) and then it gets stuck on 10-20 modules. The status of all these HTTP requests is simply Pending and they never finish. There are no errors in the browser or on the command line.
I don't think any particular file causes this. Maybe the problem is in my deeply nested folder structure with a lot of re-exports using index.ts file on each level. It mostly gets stuck on my own modules but I've also seen cases when it was waiting for a module of some external library.
Has anybody experienced a similar problem? How did you solve it?
EDIT: I have discovered that this issue only occurs in Chromium-based browsers (Google Chrome, Brave, etc.) on Linux. It works without any problems in Chrome on MacOS and Windows as well as in other browsers (Firefox, GNOME Web, etc.) on Linux.
Thanks to this comment, I realized this was a problem with the file descriptors limit.
On Manjaro Linux (Arch-based), I was able to solve it by adding the following line to both /etc/systemd/system.conf and /etc/systemd/user.conf file:
DefaultLimitNOFILE=65536
After this change, Vite works without any problems in all browsers.
Vega seems to intend to compile away both ... and =>. This is not supported in IE11 browser. Anything can be fixed to support IE11 browser?
We are using in angular 7 projects but it fails on module load for IE.
As described in Vega's Supporting Internet Explorer page, Vega does not directly support Internet Explorer. However, you can use a transpiler like Babel as part of your application build process to transform the resulting code and target a wider range of browsers / platforms.
With Firefox discontinuing the use XUL overlay it raises concerns that Selenium IDE requires this overlay to function. Can anyone confirm one way or the other?
Mozilla Will Deprecate XUL Add-ons Before the End of 2017
Selenium IDE is definitely an overlay/XUL based add-on. It contains an instal.rdf file and chrome.manifest file which uses the overlay directive.
Mozilla has stated that all types of extensions, other than WebExtensions, will be disabled in the near future. They have stated that the target for this is the 2017-11-14 release of Firefox 57. This deprecation may include complete themes, which they have stated "we will provide more details on what’s coming for themes very soon". That XUL based extensions would be deprecated was announced on 2015-08-15. The fact that they would be disabled in Firefox 57 (late 2017) was announced on 2016-11-23.
Mozilla has previously stated that such add-ons will not be explicitly disabled in Firefox Developer Edition and Nightly. However, a primary reason for deprecating such add-ons is that Mozilla wants the freedom to change the underlying Firefox code without worrying about add-on compatibility, other than WebExtensions. Thus, Firefox may change such that the features such add-ons rely upon are no longer available. Another alternative would be to use an Extended Service Release (ESR) version of Firefox. Firefox ESR 52 will be the current ESR at that time. My answer to "How to develop legacy Firefox add-ons in the future?" has more detail about possible options for continuing to use legacy add-ons.
I have not seen anything from Selenium IDE describing their plans for this change.
Right now, we're dealing with bugs in our web app that only seem to be occurring when IE10 is in Metro mode. When IE is run from the desktop the errors do not occur.
Questions:
When IE10 is in Metro mode, is it effectively a different browser version than when it's run from the desktop? Would this explain some of the behavioral differences we're seeing?
If it is a different version, is there a resource that explains the differences?
Specifically worried about rendering engine differences or JavaScript versions.
Yes, there are two different versions of IE10: Metro/Windows UI and the desktop version. Here is the official documentation from Microsoft that explains the similarities and differences: http://msdn.microsoft.com/library/ie/hh771832.aspx
Is there a development tool plugin for Safari much like how there exists the Firebug plugin for Firefox?
Firebug is great, but Safari provides its own built-in development tools.
If you haven't already tried Safari's development kit, go to Safari-->Preferences-->Advanced, and check the box next to "Show Develop menu in menu bar".
Once you have the Develop menu enabled, you can use the Web Inspector to get a lot of the same functionality that Firebug provides.
http://getfirebug.com/lite/Safari.html
http://getfirebug.com/firebuglite
Why do you want to use Firebug if Safari already comes with great Developer tools? :)
As Matt said, you can enable them from the preferences menu.
Here you will find an overview, summarized, of the Safari's Web inspector, and how to use it:
Other than the builtin developer tools, there is none that i know of. You might, however, be able to use Firebug Lite.
The Safari built in dev tool is great. I have to admit that Firebug on Firefox is my long time favorite, but I think that the Safari tool do a great job too!
If you want firebug for Safari, you just have to go to the apple extensions and search for Firebug
Firebug
I work a lot with CSS panel and it's too slow in Safari Web Inspector. Apple knows about this problem and promise to fix this bug with freezes, except this thing web tools is much more powerful and convenient than firebug in mozilla, so waiting for fix.
Firebug lite plugin in Safari extensions didn't work (it's made by slicefactory, I don't think it's offical).
btw, #2 works for me!