Show HN: %%30%30: A Game
github.com
github.com
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!)
https://tools.ietf.org/html/rfc3986#section-2.4
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.
Also, %00 shouldn't cause the browser to crash, and the fixes suggested so far are just work-arounds :/
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.
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.
more details here on the bug in chromium here: https://code.google.com/p/chromium/issues/detail?id=533361
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.
"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.
Try hitting Cmd + , to change change some of your HN settings, or alt-tabbing to your HN tab (the one in your browser).
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.
...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.
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.
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.
HTTP/1.1 302 Found
Connection: close
Pragma: no-cache
cache-control: no-cache
Location: /%%30%30
Also why not just implement the game in javascript using mouse position events and a canvas for drawing?
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!
Anyway fixed! The the instructions reads "Mouse your way through the map without touching the /trees/!"
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...
Now, what should the Markdown syntax be...
edit:
> 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.
http://www.unicode.org/reports/tr51/index.html#Design_Guidel...
Sorry for being blunt, but is this sarcasm, or did you absolutely miss the point of the "game"?
https://github.com/szhu/3030/issues/3#issuecomment-141854443
The only brower I've tried that manages to get a page is firefox[1]
To OP: i wonder, how did you find this bug?
I found it because someone posted about it in a school Facebook group I am in.