You are currently browsing the Browsers archives.

Quick Tip: Resolving Chrome Dev Tools Variable Hover Issue

Thursday, January 16th, 2020

With the Chrome (~79) update, you may have noticed that the Dev Tools variable hover > value feature has been broken. This issue is covered by 1033022 in Chromium; though, a stable fix for version 79 remains elusive.

For me, this was one of those “You don’t know what you got til’ it’s gone” type of situations as, I have become rather accustomed to this feature, and so having to rely on the Scope Panel has became quite tedious.

The good news is (or at least what has worked for me) was I was able to resolve the issue by simply uninstalling, then reinstalling Chrome. While generally this should be a last resort solution, and the fact that it actually worked is rather odd in that the same exact version was installed, it has worked, and so I figured I’d share for others to give a try until a proper fix is in place in Chrome 80.

NET::ERR_CERT_INVALID Trick

Thursday, October 22nd, 2015

So here is an utterly ridiculous trick that may actually prove to be quite useful should you ever need it.

With recent Chrome updates, hosts which fail to provide a valid SSL certificate are blocked via a NET::ERR_CERT_INVALID error. This essentially is the result of a secure site failing to provide a valid SSL Certificate in some way. In Chrome, when this occurs, you will see a screen similar to the following:

NET::ERR_CERT_INVALID

Previously one could circumvent this by clicking on a link which would allow you to override the error. However, such links in current builds of Chrome are no longer provided.

Interestingly, the work around for this is simple, bordering the ridiculous. Just focus on the page and type “danger“. The page will then automatically refresh and load as if the certificate was valid from that point on.

Obviously you want to be mindful of this work around (e.g. only using it for known hosts, such as a dev environment, etc., as was the case in my example).

Clearing Web Notifications Permissions in Chrome

Tuesday, December 3rd, 2013

When implementing features which leverage HTML5 Web Notifications, specifically in Chrome, it can be rather convenient to have the ability to clear notification permissions from the host for which the feature is being implemented.

As would be expected, Chrome allows for easily managing any setting; however, one needs to navigate through quite a few of Chrome’s settings in order to locate Web Notification permissions, the path to which being:
Settings > Show advanced settings… > Content Settings > Notifications > Manage Settings…

Navigation of settings can be simplified by using Chrome’s Search box, which allows for quickly navigating to any specific setting:

While Chrome’s settings Search feature is quite useful, it still requires more interactions then desired. Fortunately, there is an even simpler approach for quickly accessing a specific setting, in this case, Notifications.

Simplifying Clearing Web Notification Permissions

Web Notification Settings can be directly accessed for all hosts via the following path:
chrome://settings/contentExceptions#notifications

As with any URL protocol, the above path can be bookmarked, allowing for easy and convenient management of Notifications.

Bookmarking Chrome Settings

While the focus here may be on the topic of managing Web Notification settings, it is important to note that any Chrome setting can be bookmarked as a convenience shortcut for quickly navigating to any given setting. For instance, Chrome’s cache setting can be bookmark at:
chrome://settings/clearBrowserData

Then, commonly used settings can be accessed simply from their respective bookmarks:

HTML5 Input Elements on iOS

Saturday, September 7th, 2013

Perhaps some of the most important UX considerations to make are those surrounding the simplicity with which forms can be completed. This is especially important when taking into account the constraints of Mobile devices.

Input Elements and the iOS Keyboard

While implementing a form for a Mobile Web Application, I found myself in need of a way to control some of the default behaviors of the native iOS Keyboard. Specifically, I found it rather inconvenient on the user’s part to require manual closing of the keyboard of any kind, especially after submitting a form. I also found it inconvenient to have to manually turn off auto capitalization on input elements, or having to work around the default auto-correct behavior on input elements.

Fortunately, these issues (as well as others) have solutions which are readily available, both natively and programmatically.

Turning off auto-caps

By default, the iOS Keyboard displays with Caps Lock on for the first charachter on input elements of type text. For certain use-cases, such as entering usernames, this may not be desirable.

Caps Lock can be turned off by simply defining an autocapitalize attribute with a value of off on input elements:

Turning off auto-correct

As with with Caps Lock, in iOS, by default, input elements of type text have auto-correct enabled. For certain use-cases, again, such as entering usernames, this may not be desirable.

Auto-correct can be disabled by simply defining an autocorrect attribute with a value of off on input elements:

Automatically closing the Keyboard

When submitting a form, at times, the iOS Keyboard may not automatically close. This is quite a usability issue as Users should not be required to manually close the Keyboard for use-cases in which they would otherwise not expect the need do so.

A simple solution for this can be implemented by invoking the blur method on document.activeElement, which effectively allows one to programmatically hide the keyboard:

HTML5 Input Attribute Types

In addition to controlling the default behavior of the iOS Keyboard, specific types of Keyboards can be invoked simply by defining a supported HTML5 input element type.

The following examples demonstrate just how easy it is to display a context specific keyboard:

The Email keyboard can be invoked via the email input type:

The URL keyboard can be invoked via the url input type:

The Telephone keyboard can be invoked via the tel input type:

The Numeric keyboard can also be invoked via the pattern attribute, the value of which being either of the following Regular Expressions [0-9]* or \d*:

You can try the above examples here, or view the gist.

Invoking Native Mobile Applications with URI Schemes

Wednesday, July 10th, 2013

In a previous article, I outlined how the native iOS Keyboard and it’s behaviors can be managed with HTML5 input types. In addition to this, iOS, Android and most A-Grade Mobile platforms implement standard URI Schemes (or parts thereof), which allow for easily launching native applications.

URI Schemes

When considering URI Schemes, more commonly (though incorrectly) referred to as protocols, one typically thinks in terms of the more ubiquitous schemes: http, ftp, file, mailto, about, data:uri and so forth. However, as with these and other common URI Schemes, there are additional schemes which allow for various practical applications in the context of Mobile Web Apps; the most common of which being the ability to invoke a platform’s native phone or messaging application, respectively.

URI Schemes and Mobile Devices

In the context of Mobile Web Applications, the tel, and sms URI Schemes are perhaps the most common and applicable; providing a simple means of invoking their corresponding native applications. The following are basic examples which work across all major mobile platforms.

The tel URI Scheme

The tel URI Scheme allows for launching a device’s native Phone application in the context of the phone number specified:

The sms URI Scheme

The sms URI Scheme allows for launching a device’s native Messaging application to send an sms message, or to send an sms message to the phone number specified:

As can be seen in the above examples, hyphens are used in the same manner as one would typically specify a phone number; however, use of visual separators are purely optional – they can be used to aid in readability if desired, but are otherwise ignored when parsing the URI.

As a general best practice, one should take care to ensure both tel and sms URI Schemes are defined in lowercase, so as to ensure portability across platforms. Additionally, it is important to note that the sms scheme is not implemented to completion against it’s formal definition on any platform (see section 2.2 of rfc5724); thus, an sms message body, or sending an sms message to multiple recipients is not supported.

While there is nothing particularly ground breaking about these URI Schemes, or technically complex for that matter, they do prove to be quite useful in the context of Mobile Web Applications. As such, they are certainly worth noting as each can be leveraged to improve the usability of an application.

Styling HTML5 placeholder attribute text

Saturday, June 15th, 2013

HTML5 placeholder attributes can be leveraged to provide a convenient means of indicating required input formats.

By default, browsers typically implement placeholder attributes as light-grey text. As with all default user agent styles, one will feel compelled to define custom selectors to provide application specific styles to elements, placeholder attributes included.

Styling Placeholder Text

Styling placeholder attributes on input and textarea elements is rather simple; however, one should take care to keep style declarations limited to those of a textual nature; e.g. color, font-size, font-family, etc.

As it stands, HTML5 placeholder attributes can be styled with pseudo-elements in WebKit, and pseudo-classes in both Firefox and IE10; all of which (currently) require vendor prefixes.

Placeholder attribute text can be styled for all supported input element types (text, search, url, tel, email, and password) as follows:

As can be seen, defining styles for placeholder attribute text is quite simple, and such styles can be employed to add subtle enhancements to form elements in modern web apps quite nicely.