Browsers

I’m using a JavaScript text editor library and when it fails to load, there is no form field on the page at all. While pondering that potential issue, I learned how to block a URL in Chrome’s DevTools. There are a few way to do this; the most direct for me is: Open DevTools and the Network Tab Click “JS” and find the JavaScript file I want to block Right-click and choose “Block request URL” or “Block request domain” Reload the page to see the result.

The Chrome DevTools Network Tab is incredibly useful for frontend web development, but it can be noisy. Perhaps you’d like to filter it down by HTTP status code? See only redirects, so you can fix routes? Or only successful requests, so you can know what’s working? The Network Tab supports this. Here’s a filter to just temporary redirects: status-code:307

Open Chrome DevTools, and click the three dots in the top right corner. Select ‘More Tools > Sensors’. Under ‘Location’, set your timezone override.

Do you use bookmarks in Chrome, and also take a lot of browser screenshots? If so, read on. I don’t like including my Chrome bookmarks in browser screenshots; they are irrelevant and personal. Today I learned that the CMD + SHIFT + B hotkey toggles hiding/showing the Chrome browser bookmarks bar. My workflow is toggle off the bookmarks, take a clean browser screenshot with CMD + SHIFT + 4, SPACE, ENTER, and then toggle them back on.

I recently delivered a form that was hidden via CSS, using the BassCSS hide class, and encountered an issue: iOS customers’ browsers were and trying to autofill this hidden form with their saved passwords. What was going on here? hide it imparts these styles on its target in my Chrome: .hide { position: absolute !important; height: 1px; width: 1px; overflow: hidden; clip: rect(1px,1px,1px,1px); } This worked visually, but it didn’t hide the form from iOS. Browsing the BassCSS docs, I learned that this is an ‘accessible’ hide, meant to visually hide an element from view but keep it available to screen readers. No wonder iOS was confused. ...

Yesterday I wrote about Chrome Flags; today I’ll explain why. Chrome is currently rolling out sweeping changes to how it handles cookies. I learned a lot about it this week. To summarize, cookies that don’t specify a SameSite attribute will be treated as SameSite=Lax by Chrome starting with version 91. Ask for those cookies from a different URL, and Chrome won’t share them. This means that cookies intended for third-party or cross-site sharing must specify SameSite=None and Secure. You can opt into this behavior today with the aforementioned flags. ...

Chrome is making changes all time time; ignore them at your peril. Today I discovered Chrome’s Flags menu, which lets you opt-in early to features that may soon be the default. Explore it at: chrome://flags/

The HTML date input tag allows you to request dates in a web form. <input type="date"> This tag is more semantic for date input than text, and provides a side benefit: Google Chrome will automatically display a calendar selector on the page.