Hacker News new | past | comments | ask | show | jobs | submit login
Show HN: %%30%30: A Game (github.com)
608 points by szhu on Sept 20, 2015 | hide | past | web | favorite | 89 comments

You know you've been working with ASCII for a long time when you can automatically unescape the title... and then pause, considering whether to unescape again.

I think reading the comments on that bug is also rather enlightening; points of note include a 62-level-deep stack trace, comments to the effect of "we don't know what the bug is/how this is supposed to work", and discussions about whether escaping multiple times is the solution (absolutely not!)


Implementations must not percent-encode or decode the same string more than once, as decoding an already decoded string might lead to misinterpreting a percent data octet as the beginning of a percent-encoding, or vice versa in the case of percent-encoding an already percent-encoded string.

Seriously, I'm quite surprised that basic URL handling is still a problem. Making a game to bring this to the attention of a wider audience is certainly a good idea.

Reading the bug report: https://code.google.com/p/chromium/issues/detail?id=533361 makes me sad. Recursing is definitely not the answer, yet it gets brought up a lot.

Also, %00 shouldn't cause the browser to crash, and the fixes suggested so far are just work-arounds :/

> Recursing is definitely not the answer, yet it gets brought up a lot.

Speaking as someone with an apostrophe in his name, I'm not sure whether this makes me want to chuckle and reach for the popcorn, or bang my head against the desk. The answer to multiple (un-)escaping bugs is never recursion.

> Seriously, I'm quite surprised that basic URL handling is still a problem. Making a game to bring this to the attention of a wider audience is certainly a good idea.

I think the problem is that a spec exists, but existing browser incorrectly implemented it (hello Netscape), and given their prevalence browsers are stuck with weird hacks so that existing websites continue to work.

In particular around percent escapes there's lots of trouble. Nothing really specs the encoding to be used for those percent escapes (the RFC only has some odd notes on encodings), and there's a whole bunch of odd behaviours, e.g. how characters are handled when pasting a URL into an address bar vs having it as an href on a web page.

It's surprising that this issue was brought up multiple times as a bug, but wasn't taken seriously until it got special attention. This bug is definitely notorious, I wonder setting a similar URL as the homepage of Chrome will cause Chrome to continuously crash and make it useless.

The crash was definitely not there in the beginning, since I happened to have Chromium 22 (from 2012 - when I first tried it), and although it doesn't crash with %%30%30, it also refuses to visit such a URL. Someone with suitable tools should be able to do some bisection to narrow down exactly when it was introduced.

http://github.com/%%30%30 pasting this in slack also crashes Slack.

Explanation for why this is occurring:

Slack's desktop apps are HTML5 webapps wrapped inside native desktop wrappers. Specifically, Slack uses Github's Electron (formerly, Atom Shell) which is basically Chromium. The desktop app is a webpage inside Chromium.

Yeah, I strenuously object to the fad of calling wrapped web pages 'native apps'. They get zero benefits that would normally accrue to real native apps. They just launch 'as if' they were native.

Thank you. People calling web-render wrappers "native applications" must not realize how great it is when applications are mere coördinators on top of an integrated platform full of services designed to improve user productivity.

I guess if that demographic did, there would be less "unix philosophy" cultism, as the efficacy of the unix shell is merely on par with that provided by other relatively coherent software toolsets. The shell is really pretty barebones compared to the rich semantics provided by many toolkits and object systems on which user interfaces have been built: GObject and NeXT are two modern examples.

[That said, where shell shines is by providing so few abstractions that virtually any garbage has the same semantic depth as things which were designed to be used in the shell. Bytes are universal on the common computing substrate.]

The web, on the other hand, is a platform "designed" by the erosive flow of eyeballs during the 1st-nth browser wars, without much of a direction beyond tacking on additional pretty features without breaking backwards compatibility too much.

Attributes like a11y, embeddability, composability, and effective resource sharing tend to simply fall out of well-designed platforms. The web has an effective answer for none of these desirable concerns. Look at how screen readers break on js-heavy and dynamic web pages, the ongoing security disasters of XSS and iframes (and the complexity of login services like Facebook's/oauth/openid), the disappearance of Google reader, and the half-assed way CDNs offer partial, ad-hoc offloading of some resources via surrender to centralization.

> Attributes like a11y, embeddability, composability, and effective resource sharing tend to simply fall out of well-designed platforms. The web has an effective answer for none of these desirable concerns.

...what? The web is better than most native platforms in these.

The web is accessible. It has many features for screen readers and such, but more importantly, it is inherently flexible and allows content's form to be adapted to the reader's needs, thanks to the separation of content from style. A single web page, unmodified, can work on a desktop PC with a mouse and keyboard, a capacitive touch device the size of your palm, a stylus-input device the size of a laptop, a printed page, a screen reader, a ten key mobile phone from yesteryear, and more. The web lets users define custom styling that meets their needs, lets users selectively remove content (ads, for example), etc. No native platform is that flexible. Yes, some sites break screen readers, but this is true of native apps as well.

The web is incredibly embeddable. Any web page can, with one line of code, incorporate any other web page, and it "just works". You simply can't do that with native apps.

The web is composable as well. Sites can load JavaScript from each other very easily.

The web also supports resource sharing in various forms, but people don't necessarily use them.

Alas, all the benefits you list are just possibilities, not the reality. "separation of content from style" was a big thing back when csszengarden.com was making rounds, but that all is long forgotten in the name of angularreactnodecrap. Accessibility? Give me a break, how many web sites do even work without JS enabled? I am not sure about Android, but iOS has a great accessibility support.

It’s a common misconception that Javascript precludes accessibility. JS can in many ways help accessibility if done considerately.

Separating style and content isn't dead. It's more popular than ever. HTML5 has brought in new semantic markup and discouraged presentational markup. Most sites even today work fine without CSS.

Screen readers support Javascript, if that's what you had in mind. http://webaim.org/projects/screenreadersurvey5/#javascript

There are some of us who still adhere to semantic HTML.

I agree that these are all legitimate problems, but over time the wrappers themselves will eliminate a lot of them. There will always be "native" wrapped HTML apps that do a bad job of taking advantage of the platform. That's the case with any adapter platform that lets you code once and deploy everywhere (look at 90% of Java-based apps). But that doesn't mean that it will inherently be a bad idea.

Indeed, Electron already is starting to provide these kinds of facilities. For example, it allows you to load native node modules, and it provides some tools for integrating with the desktop envirionment (see https://github.com/atom/electron/blob/master/docs/tutorial/d...).

Side note:

> coördinators

I knew I wasn't the only one who loves this pretentious diaresis style. Stay strong, brother/sister/sibling. Stay strong.

What does the disappearance of google reader have to do with the problems of native vs webapp design?

"They just launch 'as if' they were native." That's a pretty big benefit to most end-users.

That could be the greatest thing in the world, but it doesn't make it a native app.

I don't know why you're getting downvoted. I've seen studies that say 80% of users prefer apps over the mobile web. I know I've certainly seen an almost hostile attitude towards web app offerings over native app versions. And it all seems to boil down to one thing. You can get good-enough access to just about everything on the phone through an HTML5 app--certainly enough for a large proportion of apps--except for "installs through the app store".

> I don't know why you're getting downvoted.

"A is not B"

"but A has C properties"

Native apps are not defined in terms of having benefits; they have specific technical characteristics that embedded webpages just don't have. So the fact that embedded webpages may or may not have benefits is irrelevant to the statement that they are just not native apps. I guess that's where downvoters are coming from.

For Slack I believe the discussion was desktop app vs web app, not mobile web app vs native mobile app.

Well, the benefits of Electron or NW.js compared to a Web App are things like filesystem access - as well as the entire Node JS ecosystem, which has many modules, some capable of performing native operations in a variety of different platforms.

What do you mean by 'as if'?

Try hitting Cmd + , to change change some of your HN settings, or alt-tabbing to your HN tab (the one in your browser).

Don't think I've ever heard or read anyone claim this, just that they live in a native wrapper.

I think this should be the future of native apps. You do get all of the benefits of native apps -- there are plenty of modules to handle key bindings, notifications, file system IO, etc. By using web page rendering you also get the incredible ecosystem of front-end tooling and plugins (React, Bootstrap, the infinite jQuery plugin world). All of this beats Qt in my opinion, having designed both.

You certainly do not get all the benefits. In particular you miss out on the shared "UI vocabulary" that comes from building on a common toolkit. This vocabulary means that users already know how to use your app, because you follow the platform conventions. Build on web technologies, and you are left either ignoring the conventions entirely and producing something very alien, or trying to recreate them from scratch and falling into the uncanny valley.

For example, look at Atom. I can type Command-Z on my keyboard to Undo, but it's non-native-feeling in lots of ways:

1. The menu bar doesn't highlight to register that I typed a key equivalent

2. The Undo text doesn't change to e.g. "Undo Typing," telling me what I will Undo

3. The menu item doesn't properly disable when there is nothing to Undo

4. The menu item doesn't respect my settings in Keyboard preferences

etc. etc. And that's just one feature - but it's every feature.

Needless to say, that stuff comes for free or with very low friction natively.

Qt is a bad representative of the native experience, because Qt is non-native everywhere except on Linux, which doesn't have strong UI conventions to begin with. Qt apps definitely feel alien on the Mac.

It's Chromium? Then why do the Slack folks keep saying the preferences UI bug is a Webkit bug? It can't be a Webkit bug if they're using Chromium.

Depends on the platform. For Apple devices and workstations it's a wrapped Safari web view, which is not affected by the bug, and does not crash.

I wonder how many other apps will also have this bug due to being a webapp inside Chromium, and thus require updating when it's fixed. It's not Heartbleed-like criticality, but still seems rather unpleasant, not to mention the waste of keeping multiple copies of Chromium around (I'd guess the typical webapp is much smaller than the browser itself.)

I had to switch back from Atom to Sublime to make this, because Atom is based on Chromium :(

even hovering mouse over this link in the comment above crashes chrome

That's exactly how the game works!

thanks, I got it, but didn't realize it was THAT simple :)

more details here on the bug in chromium here: https://code.google.com/p/chromium/issues/detail?id=533361

Funnily enough, opening this url gives a GitHub Server Error.

Yup, opening this on my own website (hosted using GitHub's repositories) also gave me an error.

If you paste the link in chrome and visit it, crashes the whole browser not just the tab.

My little web client just prints this header with no body:

    HTTP/1.1 302 Found
    Connection: close
    Pragma: no-cache
    cache-control: no-cache
    Location: /%%30%30
Maybe the infinite loop is the real problem here.

Hovering over this link also makes it crash like when you hover over the trees

Amazing. I always love seeing these sorts of harmless, fun ways that bring attention to these strange edge/corner case bugs.

Reminds me a bit of the doom variant that would kill a random process for each enemy you killed.

you're probably thinking of http://psdoom.sourceforge.net/

There's also this arcade-style shooter which kills a random file for each enemy. A bit riskier.


You probably want to make it more clear that you're supposed to mouse over the dark lollipops and avoid the blue trees. I assumed the dark chars were the walls I shouldn't touch and just about gave up on it after it was constantly crashing. Then I read the description after the fold and figured it out.

Also why not just implement the game in javascript using mouse position events and a canvas for drawing?

Dark lollipops? Blue trees? What operating system are you using? I'm on a Mac and the lollipops are pink and the trees dark green. I'm considering making a text-only version for people who have weird or no emoji support.

Of course I could implement the game in javascript, with nice graphics and all, and perhaps gameplay that works in all browsers and doesn't crash Chrome, but wouldn't that defeat the point of the game? :)

Happy to take PRs though!

what?? you're crazy, mine are white and gold!!

I'm on Chromium on Ubuntu. Also have Dark lollipops and Blue trees, guest it depends on the font or something.


When was the last time you've had a black lollipop? Or seen a blue tree? Thanks, Ubuntu.

Anyway fixed! The the instructions reads "Mouse your way through the map without touching the /trees/!"

It's not ubuntu's fault. Ubuntu/FF here, and I'm getting green trees in FF, blue in Chromium.

Blue trees can be seen in mountainscapes in certain light conditions. Or in the Blue Mountain... well, the trees themselves aren't blue, but they're covered in a blue haze... but still, the emoji is evergreen_tree...

Yep, on Ubuntu here too and it's exactly like that.

The trees inherit #4078c0 from "a" on chrome. The lollipops are #333 inherited from "body". I see exactly that on linux, I have GNU unifont installed. I guess since Mac's are using colorful bitmap emoticons they simply disregard the color property.


> weird or no emoji support.

I think Apple's emoji support is the weird one. It's a font glyph, it should respect the color property.

Emoji glyphs are not supposed to respect the color property.

Apparently emojis can have "emoji representations" (colorful) and "text representations" (foreground color) [1]. I feel that emojis have no place in unicode though.


It's a shame <marquee> is gone, otherwise you could've put in moving barriers ;)

News to me. data:text/html,<marquee>hodor</marquee>

Huh! I assumed support was gone, seeing as it's been deprecated for a long time.

Now, what should the Markdown syntax be...

Windows 10, Chrome, https://i.imgur.com/fMrRYPN.png

Lime green lollipops and dark green trees on Chrome for Android.

That is how they appear on windows.

>Also why not just implement the game in javascript using mouse position events and a canvas for drawing?

Sorry for being blunt, but is this sarcasm, or did you absolutely miss the point of the "game"?

Here's a suggestion that replaces the lollipops with something else. Please comment on the PR if you prefer it instead— https://github.com/szhu/3030/pull/2


I must admit my tab crashed before I figured out what was going on lol.

hm, looks like that bug has been reported already: https://github.com/szhu/3030/issues/1

That's the whole point of the "game". To show this bug.

My inspector even crashes when trying to hover over the link node!

The game doesn't "work" on microsoft edge but the brower doesnt recognize the Stanford links[0] , it is not possible to copy them by right clicking. Going directly to the page by copy/pasting the url doesn't even load the website. IE doesn't seem to understand the url as well.

The only brower I've tried that manages to get a page is firefox[1]



Old Opera 12.17 (last version that still allows specifying a different proxy than the system one, afaics) shows the same page as Firefox. Elinks does as well.

This is a beautiful experiment.

To OP: i wonder, how did you find this bug?

It's actually all over the news right now: https://www.google.com/search?q=chrome+url+bug

I found it because someone posted about it in a school Facebook group I am in.

This works in Chrome on Android as well. Of course it's way easier than on desktop.

Try it in landscape mode.

I like how this crashes Twitter app's "preview" browser with app itself.

This weirdly makes my external monitor flash black when I open this tab. What's going on here?


You can jump over the wall by scrolling your mouse! :D

Works with Opera 32 as well.

Of course. It is just a chrome fork with minimal changes.

Crashes my Chrome (Windows) when I move mouse pointer over the game area.

That's the point.

Nice. It crashes my Chrome on hover over trees.

Aw snap! Always.

Hahah, clever.

Creative. Nice project.

hah, another chrome-only thing

This game has free graphics upgrade if you use "Emoji Input by EmojiStuff.com" extension

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact