Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Everything about Google Translate crashing React (and other web apps)

martijnhols.nl

Post reply on HN
Print view View original

71–80 of 88 posts

Re: Everything about Google Translate crashing React (and other web apps)

#71

Post by MatthiasPortzel »

shadowgovt wrote: post #63
cmenge wrote: post #49

I had to learn this the hard way when a React app I built showed random crashes I couldn't explain. "Fortunately" it also auto-translated the "I happily accept the terms of use" checkbox in one case into (back-translated) "I happily dying die perish", which also couldn't be clicked. That lead to a very high priority ticket and made us realize that all DOM manipulators might break the site.

Very early on in my career, I was working on a greeting-card app in Facebook (back when Facebook apps were a thing). Got a bug report from one of our own team members that some of her greeting cards didn't show up in the list. The link appeared, but no image. We figured out that the difference was she was running an ad-blocker. We couldn't figure out precisely what rule the blocker was applying, but it seemed to be:…

> I still won't run my own ad-blocker for this reason.

I maintained an extension for a public website for a couple years. (It did things like, for example, adding information that was available in the API to the page, for power users.) I eventually gave up with the conclusion that the concept of a browser extension was fundamentally unsound. So I also don’t use an-blocker.

Re: Everything about Google Translate crashing React (and other web apps)

#72

Post by andrewmcwatters »

I don't like the way React updates subtrees. Other frameworks get it wrong, too, by using the same incorrect model. Employing professional opinion, it's just wrong. The document should be considered the source of truth, not some internal private state.

e.g. Input values on the HTMLInputElement are the real input, not some clone to a private object in JavaScript.

As a result of React's blatantly wrong treatment of the document.body, you have ensure that when it reuses element siblings within an arbitrary tree, that it's values are squashed to whatever private fields you're using in your component.

It screams wrong, and side effects like the one in this article make it obvious why.

No one is going to go out of their way to touch your special internal state, we're all going to use the web API to touch nodes and events from standard interfaces. You can't take the ball into a private court and expect the rest of the game to function.

Re: Everything about Google Translate crashing React (and other web apps)

#73

Post by kelnos »

phantomathkg wrote: post #52
Freak_NL wrote: post #32

Earlier quoted context omitted.

> I will add, please make sure that language is an independent setting, and not derived from locale! Websites already have exactly what they need to provide you with the language you want via the Accept-Language header your browser sends. In your browser's settings you can configure a list of languages (country-specific if desired) which get send with every request. E.g.,: en-GB en nl (Prefer British English, fall ba…

This does not help in many many situations. I am a Hongkonger, natively speaks Cantonese, fluent in English and learning Japanese. If I go to Google I want English UI and prioritise traditional Chinese result then English then simplified Chinese. On the other hand if I go to a Japanese website, I don’t want them to translate for me, just display the original Japanese will be fine. Unless I toggle. These kind of compl…

> A toggle per site is easier than navigate three level deep into browser setting page.

I don't disagree with your overall point, that flexibility is useful for website visitors, but your statements requires asking the question: "easier for whom?"

Certainly relying on Accept-Language is significantly easier for the website maintainer. And overall it would be a lot easier if the small handful of web browser maintainers added saner settings (even a per-website Accept-Language toggle), than if we were to require the thousands (tens of thousands? millions?) of multi-language website developers to provide their own toggle. Not to mention having a standardized way to do manage this would be better for users than having to discover each website's language toggle UI.

But sure, we don't have those easy-to-use browser settings, so it's (unfortunately) up to every website developer to solve this problem, over and over and over.

(As an aside, it would be cool if websites could return a hypothetically-standardized Available-Languages header in their responses so browsers could display the appropriate per-website UI, with only the supported languages.)

Re: Everything about Google Translate crashing React (and other web apps)

#74

Post by kelnos »

VWWHFSfQ wrote: post #62
Freak_NL wrote: post #43

Earlier quoted context omitted.

That and a thousand other things. A highly privacy focussed browser could offer to enable this setting only on whitelisted websites (and send 'en' plus a bunch of random language codes on others).

> 'en' plus a bunch of random language codes This is an easier fingerprint signal than just not sending anything.

Not if the random part of the list changes with each request.

There are two ways to defeat fingerprinting: 1) make everyone look exactly the same (pretty difficult to do), or 2) introduce enough noise and randomness to fingerprinting signals to each request so that each person looks like many different people (much easier to do).

Re: Everything about Google Translate crashing React (and other web apps)

#75

Post by kelnos »

nottorp wrote: post #10
bryanrasmussen wrote: post #9

Earlier quoted context omitted.

I think the fundamental problem is you have two applications, the primary application and google translate altering the application state of the primary application at the same time, without any possible communication between the two regarding locking or alterations or anything. I'm pretty sure most applications in the history of computing would not fare any better if you constructed that situation.

Both Google and React are guilty here if i read the article right. Google replaces an element with a different element (Text with Font containing Text?), and React's virtual DOM keeps the old, deleted elements alive because the virtual DOM still references them. React "applications" would crash when Google Translate changes their stuff from under them if they didn't accidentally keep the old elements alive. Which wou…

That doesn't track with me. The React application is the website. It should be able to run while expecting some other third party thing isn't going to dig into the internals of its view and modify those internals.

It would be fine if Translate was just modifying text, but changing the actual structure of the HTML goes too far.

Re: Everything about Google Translate crashing React (and other web apps)

#76

Post by kelnos »

friendzis wrote: post #14
bryanrasmussen wrote: post #9

Earlier quoted context omitted.

I think the fundamental problem is you have two applications, the primary application and google translate altering the application state of the primary application at the same time, without any possible communication between the two regarding locking or alterations or anything. I'm pretty sure most applications in the history of computing would not fare any better if you constructed that situation.

The primary application is the browser. The problem here is that react "application" builds its own state of the web page, fails to reconcile it with changes to actual state, ends up in a detached state with stale information and then proceeds to alter actual state based on the corrupted information it has.

I disagree. The browser is a VM that runs other applications, in this case one that's written in React.

Then the browser, via an extension, is corrupting that application's internal state and is then surprised when that application stops working correctly. Well, duh.

If Translate were to only modify the text on the website, I'd think React would be able to deal with it better. But it seems to be modifying the structure too (adding tags); I think it's not reasonable to expect every JS framework to be able to deal with that properly.

Re: Everything about Google Translate crashing React (and other web apps)

#77

Post by kelnos »

zelphirkalt wrote: post #30
aqueueaqueue wrote: post #7

Earlier quoted context omitted.

I doubt it. Say you write a native app and some other side app swoops in and changes all your UI state while running. That is going to cause problems.

But only, if the DOM is used in other ways than being an output of whatever is done to calculate its update. If the framework uses the DOM for other things than directly updating it or respresentation of internal state, then that's on the framework. Is it reasonable to assume DOM itself is part of the state? Would it not be more reasonable to have an internal state? But we have this with virtual DOM. So maybe the iss…

That sounds pretty arbitrary. Upon what grounds do you feel it's appropriate to say that the DOM is only allowed to be used in the way you describe?

Re: Everything about Google Translate crashing React (and other web apps)

#78

Post by MartijnHols »

jppope wrote: post #68

Just out of curiosity, what web apps are effected? I tried to find the "other web apps" and can't find anything (quick scan of the article)

Anything that affects the DOM and relies on TextNodes behaving predictably. It could be as simple as `e.target` of a click event being different (the `font` element gets in between what was actually clicked), but the main issues are when apps try to update or replace what used to be TextNodes.

Imagine you're building a framework, and a consumer renders a clock. The only thing that changes every tick, is the text value; `00:00` becomes `00:01`. In an attempt to be as efficient as possible, it's only natural for the framework builder to decide to keep a reference to the `TextNode` and only update its `textContent` every frame. This scales the best for even the most complicated app, but it leads to interference from Google Translate as the article shows.

Re: Everything about Google Translate crashing React (and other web apps)

#79

Post by LorenPechtel »

shadowgovt wrote: post #63
cmenge wrote: post #49

I had to learn this the hard way when a React app I built showed random crashes I couldn't explain. "Fortunately" it also auto-translated the "I happily accept the terms of use" checkbox in one case into (back-translated) "I happily dying die perish", which also couldn't be clicked. That lead to a very high priority ticket and made us realize that all DOM manipulators might break the site.

Very early on in my career, I was working on a greeting-card app in Facebook (back when Facebook apps were a thing). Got a bug report from one of our own team members that some of her greeting cards didn't show up in the list. The link appeared, but no image. We figured out that the difference was she was running an ad-blocker. We couldn't figure out precisely what rule the blocker was applying, but it seemed to be:…

Which is why a decent ad blocker has the option to selectively permit things it thinks are ads. Without blocking I've had multiple occasions of encountering a website that was completely unusable, it would be completely overlaid with ads as soon as they loaded.

Re: Everything about Google Translate crashing React (and other web apps)

#80

Post by LorenPechtel »

mostlylurks wrote: post #67
JimDabell wrote: post #51

Earlier quoted context omitted.

I don’t see why Google Translate wrapping all text in elements is reasonable. Why is an extra element required, and why is it of all things? Translate is swapping text for text, so this shouldn’t be necessary. It also breaks a lot more than just JavaScript frameworks. Things like the child combinator in CSS selectors will break too.

> Why is an extra element required, and why is it of all things? I don't know, but perhaps due to the fact that due to the CJK unification in unicode, rendering Chinese or Japanese without explicitly setting a font designed for that particular language can output incorrect characters (of the other language, which are considered "the same character" despite being different). Thus, a translation tool would have to expl…

I doubt that's the only case. We have multiple languages that have applied their own solutions to digital representation and the attempt to maintain backwards compatibility inevitably sets up trouble.
Post reply on HN