Usually when I see this from non-spam sites, it's not even pushstate, it's just some page that redirects as soon as it loads. So you press back twice and it goes back -> forwards -> back -> forwards. Disabling pushstate doesn't fix that, it just makes pushstate equivalent to a redirect.
That's relatively easy to work around. Right-clicking on the back button lets you go back several steps at once. I don't know about Chrome, but it does work on Firefox.
AFAICT just holding left-click for half a second has the same effect. That's been my go to since the little triangle dropdown vanished from the back button (checks watch).. uh, some time in the nineties mebe?
On qutebrowser I type 2H instead of H, and it doesn't go to the most recent history item at all. Mostly though, no, spammy websites still do this, and browser's haven't fixed it.
Browser.history.allowPushState was deprecated in Firefox V47 (2016) once they'd restricted the ability of sites to muck with history state via JS. This used to be a pretty big issue but as a daily Firefox user for 20 years, sites changing history state hasn't been a problem in recent memory, so whatever they did works pretty well.
But the TFA is about a related issue with a similar symptom, hijacking (or disabling) the back button in Chrome browser. This also hasn't been an issue in Firefox in recent memory (kind of shocked to learn it still was until now in Chrome). However, I did have a problem in recent years in Firefox with sites hijacking the Browser_Back keycode and/or hotkey (keycode 166 or Alt+Left Arrow) but I solved it with a small UserScript I posted elsewhere in this thread.
I rarely click the back arrow icon on the interface since I have a three-finger tap on my touchpad assigned to send the Browser_Back keycode when the active window is Firefox. Being a keycode, this can be intercepted by site JS. While sites intercepting Browser_Back (keycode 166) is rare, some video players use the arrow keys to skip forward/back and Alt+Arrow to skip more. Since Firefox uses Alt+Left Arrow as the back hotkey, this can be an issue. I fixed it with a UserScript that prevents sites from blocking certain keycodes. Note: you can also change all Firefox's hotkeys by going to "about:keyboard".
What about SPAs tho? Some of the state is in the URL, and as the user fills the form, you might push state to undo last step of the form. Does this mean that in this context the user gets thrown to about:blank? That would break tons of websites.
I use all kinds of web apps and forms and have no issues with undo or other features. And the changes Firefox made to prevent malicious JS changing browser history were done in 2016. I don't think it has anything to do with undo within a page and I wouldn't expect the browser back button to replicate undo (ctrl + z).
As for my small UserScript, it has nothing to do with browser history state. It simply forces web site JS to share certain key strokes with my browser, add-ons and scripts instead of swallowing them (and it's easy to include/exclude any site or page).
Single Page Applications use the History API to create a working back/forward history within the SPA. This will cause you to navigate away on use, and potentially lose data.
Speculation for fun: I always thought popular apps can use private apis or are handled in a special way by the OS itself. If yes, perhaps this is related.
Then again I found no source for that - and some certificate rollover seems more likely.
It’s a completely opposite scenario for me, I accidentally shipped a pixel art game.
It’s actually a game about nonograms. My first attempts at pixel art were bad but it didn’t matter that much, the focus was elsewhere anyway. With time the art improved; far from perfect but it’s still one of the things I like most about that game.
So I guess: practice, room for failure, achievable goals and time.
Oh no, that one has proper pixel art. Mine just has pretty puzzles (nonograms that turn into pixel art images when solved) and an occasional pixel art level. I plan to add more levels like this later.
That page addresses tort liability, not liability for driving infractions or crimes. Liability for damages when a company does it is more settled of a situation.
It still isn't quite as clear who or if anyone is liable when traffic laws are broken:
Sounds like the tickets should be at least more expensive than the cost of equivalent QA (and if not, self driving companies might offload QA to the police).
However, I skip permashortlinks - I try to keep my regular links relevant and short. Also, I like seeing full links, they can often indicate what content awaits there - vs short links, which are more opaque.
That's one more benefit of this workflow: it can be adjusted to fit one's personal preferences. I suppose others might prefer short links or maybe at some point I'll change my mind; with POSSE making these kind of changes is easy.
Yeah, I’m happy to just call permashortlinks a bad idea, seldom warranted historically and roughly never now. The article offers no explanation about why to use permashortlinks—what looks to be “a few reasons why” is actually a few reasons why to link to the original (rather than copying and pasting the contents), nothing to do with the permashortlink practice.
https://indieweb.org/permashortlink does give a few reasons, but they’re bunk. “More reliable in email”? Not meaningfully so. “Quicker to recall / copy due to size”? Not typically a concern. Maybe a nice-to-have, but you can consider adjusting your URL style, then it can be even better. “Less effort to manually enter”? Repeat of the previous point.
And it doesn’t address the problems of the permashortlink. Cost. Diluting across different domains. Having something different to maintain and remember.
Don’t do separate permashortlinks. Just fix your regular links to not be bad.
> Desk Reject Comments: The paper is desk rejected, because the reciprocal reviewer nominated for this paper ([OpenReview ID redacted]) has violated the LLM reviewing policy. The reviewer was required to follow Policy A (no LLMs), but we have found a strong evidence that LLM was used in the preparation of at least one of their reviews. This is a breach of peer-review ethics and grounds for desk rejection. (...)
Anecdote, I like wired headphones for important online calls. I use earpods[1], I started using them back when they came with a phone, I'm happy that it's still possible to buy replacements. I like having a reliable wired connection that works and disconnects predictably.
I guess a lot of that is nostalgia. My laptop model no longer has a webcam cover or a physical network switch; connecting and disconnecting the trrs[2] cable reminds me of these.
But some of that is still practical needs. I have AirPods and Bose wireless headphones, both praised for reliable connections. Every now and then they take a bit longer to connect or the volume changes unpredictably, or they need to be charged, etc - when wired headphones just work.
I very much appreciate it when people use wired headphones with a decent mic for calls. Speech clarity is just so much better even with Earpods compared to tws earplugs.
> Open the about:config page in Firefox
> Search for "pushstate"
> Double-click "browser.history.allowPushState"
source: https://superuser.com/a/1688290
reply