Skip to main content

ERR_BLOCKED_BY_XSS_AUDITOR error in Google Chome – How to fix it

With the recent Chrome 57 build, the XSS auditor detection (and blocking capabilities) has been improved to the point that many web-based services suddendly stopped working giving this rather obscure HTTP error:


The issue is almost always caused by some HTML-formatted content being sent via POST within the request, which is a rather common behavior for a number of modern web tools and features – such as WYSIWYG editors, interactive uploaders, AJAX-based CMS real-time updates, and so on.

When the tool is developed by third-parties, the best thing you can do is to open an issue with the developers and make them go through the hassle: however, there are scenarios where you *need* to anticipate the fix by yourself, not to mention the cases when *you* are the tool developer. This is what happened to me yesterday, when I had to apply a quick fix to a tool I coded for a friend of mine a while ago: an interactive electronic invoice display which follows the recent italian electronic invoice PA standards. Read More

HTML input type number with (localized) decimal values using JQuery

Among the many great features introduced with HTML5 there are the new types added for the <input> elements: these are color, date, datetime-local, email, month, number, range, search, tel, time, url, week. If you’re into web design you most certainly know how painful it was to properly support these types by adding drop-down lists, inline calendars and other client-side validation scripts to force the user to insert these kind of values: as of today most of the trouble is gone thanks to these new types, because the web browser will take care of that with a built-in set of good-looking (and standardized) controls. Read More

WordPress: Theme or Plugin not working as it should? Check for duplicate CSS or JS files

We all know how a typical WordPress installation works: you start with a cool Theme that suits your tastes, add a fair share of must-have Plugins such as Jetpack, Contact Form 7, the YOAST package to handle Analytics and SEO stuff and you think you’re mostly done: you just need a blog, after all, keeping it as simple as you can.

Then you find out that you’d also like a newsletter and MailPoet gets added to the loop. And it won’t be much time until you realize that you’d also like to throw some image galleries here and there, so you browse through the hundreds of sliders & carousels in the Plugin Repository until you find a good one. And what’s better than BuddyPress to feed your community expectations? Or WooCommerce if you want to sell stuff? And why should you deprive your users of the chance to get your valuable Google Drive shared files by not installing a Download Manager of any sort?

Let’s just face it: you don’t pick WordPress to keep things simple: as a matter of fact, you want it to do complex stuff while keeping them under your control thanks its consistent, versatile and mostly modular framework interface. What’s wrong with that? Nothing. Except when these plugins start to conflict with each other, or when they keep adding the same js or css common libraries (mostly being jQuery, Bootstrap, MooTools etc.) to your pages.

Read More

Jquery.scrolling: check HTML elements visibility in Viewport after a page scroll or resize

With responsive design and adaptive layouts constantly increasing their audience, the importance of controlling the visibility of HTML elements inside the viewport is continuosly increasing. Unfortunately, neither javascript nor the popular jquery frameworks provide a native way to check the visibility status of an element after a page scroll or resize.

This is the main reason behind the development of jquery.scrolling, a jQuery plugin that does exactly this: it basically adds the scrollin and scrollout custom events that will fire when any given element becomes visible/invisible in the browser viewport. This allows you to:

  • automatically or programmatically show/hide any HTML content as soon as it comes inside or outside the browser viewport (i.e. when the user scrolls to them).
  • prevent unnecessary processing for content that is hidden or is outside of the browser viewport.
  • trigger a custom function or behaviour (such as loading external AJAX content) when a certain point of the page is reached.

and more.

Read More

Using JQuery UI and Bootstrap togheter in the same web page

In the past few months we’ve seen the Bootstrap framework became more and more popular among web developers. The reasons are fairly obvious, we’re talking  about a powerful CSS/JS enhancement library featuring a lot of useful stuff to build a responsive, mobile-friendly webpage fully compatible with every major browser/device. The most recent version of the framework (v3.3.1 by the time of this post) contains a lot of useful javascript plugin requiring JQuery v1.9.0 or higher in order to work: there’s no doubt that some of these websites are also running JQuery UI.

These 2 frameworks are indeed able to work togheter, but we need to pay attention to at least two naming conflicts between them which need to be fixed in order to avoid JS errors and, most importantly, get them to work properly. We’re talking about the tooltip and button plugins, which happen to exist in both of these libraries with the exact same name.

The Issue.

Let’s take the tooltip plugin as an example. Open the address and look at the sample code – by clicking on the “view source” link – to see how the JQuery UI tooltip plugin actually works:

The highlighted text shows a call to the tooltip function which, thanks to JQuery UI, is added at runtime to any JQuery object. Bootstrap does the exact same job, as shown in the official tutorial:

This nasty naming conflict prevents the plugins to work an might also generates some Javascript errors depending on the framework <script> references order inside the web page. For example, here’s what you’ll most likely get in your Javascript Console if Boostrap is inserted after JQuery UI and the latter’s tooltip plugin is being used:

Uncaught TypeError: Cannot read property ‘documentElement’ of null

We get this message because the tooltip plugin provided by JQueryUI has a completely different – and hardly compatible – interface than the Bootstrap plugin sharing its name.

 The Solution.

The best way to make the 2 libraries blend togheter and “constructively” fix the aforementioned naming conflicts is to use the not-so-well-known $.widget.bridge plugin, which allows us to re-define each previously assigned prototype function name. The plugin is already included inside the JQuery UI standard distribution package, so we won’t add any additional stuff to our website. The usage is quite simple:

These commands need to be executed after the JQueryUI and before the Bootstrap js file references. In the following example we can see a full implementation example in the <head> block of a common webpage:

After you do this, the tooltip and button prototype methods will be univocally routed to the Bootstrap ones: those provided by JQuery UI will also be usable as long as we call them by using the new alias we gave them: uitooltip and uibutton.

References: (my answer on StackOverflow which kinda inspired this post).