"Playwright" “enables reliable end-to-end #testing for modern web apps.” It lets you puppet #browsers to automate web browsing, similar to #Selenium. #documentation #toread
on 02025-08-27discussion of monthly #Ladybird report. #browsers
on 02025-08-02the hacks we needed to get mouse handling to work in #browsers back in the MSIE days
on 02024-08-03#interview with Andreas Kling about #SerenityOS, #Ladybird, and #browsers
on 02023-07-06the #pointerlock API for #browsers.
on 02023-06-23the #pointerlock API for #browsers.
on 02023-06-23apparently "mouselock" or "pointerlock" is implemented in #browsers now for Minetest-style mouselook? Firefox has a requestPointerLock on DOM elements anyway which fails if the document is not focused. It drops down a toast saying, “github.com has control of your pointer. Press Esc to take back control.”
on 02023-06-23apparently you can create #Web-workers from localhost HTTP URLs, but not file:// URLs, and in I guess Chromium not data: URLs, but you can create Blob URLs in #JS. If HTTP or HTTPS, the MIME type has to be text/javascript. #browsers
on 02023-06-22Explanation of #Web-workers in #JS. Normally it's like const w = new Worker('worker.js'), where worker.js defines an onmessage callback which can use a postMessage global to send back too its creator, who can handle it by setting w.onmessage to the appropriate callback. There's a synchronous, blocking importScripts in the worker that takes URLs oof libraries to load. Runtime errors invoke onerror. #browsers
Messaging #Web-workers is fast #performance even without transferable objects, but the test code here is broken #browsers
on 02023-06-22#Web-workers can transfer so-called "transferable objects" to other “agents” in the “cluster” without copying them by listing them in an array passed as a second argument to postMessage; the ArrayBuffer in .buffer of typed arrays like Uint8Array is such a transferable object, as are things like MessagePort, AudioData, and WritableStream. Agents are web workers or the DOM execution context. #JS #wasm #browsers
on 02023-06-22#Firefox #browsers consider localhost and file: URLs to be "secure contexts" for #HTML5 APIs like getUserMedia and service workers and custom protocol handlers
on 02023-02-07Mozilla’s official documentation for the #HTML5 #getUserMedia API for accessing cameras in #browsers; this has example code for things like front and back cameras. Apparently it’s deprecated, but I don’t know what alternatives exist.
on 02023-02-07how to use the #HTML5 #getUserMedia API for camera access in #browsers, step by step
on 02023-02-07the #HTML5 camera API #getUserMedia in #Firefox #browsers requires HTTPS (or localhost) since 02019; the about:config flag to allow otherwise is media.getusermedia.insecure.enabled
on 02023-02-07also in #Chromium #browsers, the #HTML5 camera API (#getUserMedia) can be blocked from a localhost port in chrome://settings/content/camera.
on 02023-02-07#Chromium #browsers allow access to the #HTML5 camera API #getUserMedia from localhost in JS, but not from file: URLs (even if you explicitly allow it yourself), though there's also chrome://flags/#unsafely-treat-insecure-origin-as-secure.
on 02023-02-07scrolling #performance and why it kind of sucks in #browsers and how to improve it in your #JS, e.g. with passive listeners. #UX
on 02017-03-22#subresource-integrity in #browsers, originating in 2015-08-24. Apparently supported in Chromium, Iceweasel, and Opera so far, but not Safari.
on 02016-10-03#Content-addressable #JS frameworks via the new SRI “#subresource-integrity” feature (<script integrity="sha-...">). “explores why content addressable caching is difficult on the Web platform, and how #browsers might sidestep these difficulties” such as timing leaks. Pretty sad, but it does suggest some feasible solutions that sound safe. #security