Comment by ebang4 | Hacker News Reader

Comment by ebang4 | Hacker News Reader

Parent Full thread

i336, hello from Redmond!

With less efficient technique, I refer to using <object>, <script>, <img> tags to prefetch content, which does not have the goodness of link prefetching mentioned in the article your shared. That is what Chrome on Linux was falling back to.

Link Prefetching is the way to go, and that is what Chrome on (Mac/Windows/Chrome OS) is currently using.

The reason why browser detection is needed is because it is not supported everywhere, e.g for instance, according to http://caniuse.com/#feat=link-rel-prefetch Safari does not support it, so StaticLoad.aspx uses the <object>, <script>, <img> technique, but unlike Chrome on Linux, Safari on Mac does not hang.

Again, this was not intentional. The second technique does not hang on Safari on Mac, but it does on Chrome on Linux. We will definitely ensure that more Linux testing is done! Our goal in OneDrive is to build a service that enables as many people as possible to be productive, so if in cases it looks like we are trying to favor our own OS, that is not really our intention.

Thanks! Edgar

Hi! Thanks for the reply! :)

I think I understand now: you added a whitelist that needed to see "Windows" (possibly alongside some other acceptable keywords) in order to serve the link prefetching implementation, and that Chrome on Linux just never got whitelisted. I'm very glad to hear that you'll be doing more Linux testing in future!

With that said, I'm now looking sideways at the Chrom{e,ium} team and wondering why using object/script/img tags is causing such massive lags on Linux - that's how most websites still work! If I may ask, what do you think were the contributing factors to the hangs? I'm guessing large code size might have had something to do with it...?

Thanks for the reiteration that this wasn't intentional, really cool to hear that. I also really like the view you have regarding different platforms :D

Edgar, you might be interested to know there are significant problems with the big javascript files being downloaded on Linux for Office365, particularly for WordOnline.

We've done similar experiments and proven it to be again based on your own user-agent detection, since normally they will take 30-60 seconds to load, causing the UI to essentially lock up and fail, when faking the agent-user to something else will work around it.

Multiple attempts at contacting Microsoft support come back with its not supported.

Its the Web... pretty sure you can build things without breaking them for Linux.

(Not ebang4)

That's interesting; sounds like a very similar issue to this one (with Link Prefetching). That said, Edgar is from OneDrive, whereas you're talking about Office365. My guess is that the departments are "just far apart/different enough," so to speak, even though the issue does sound the same.

I really liked to hear that "We will definitely ensure that more Linux testing is done!"; hopefully this is a collective mindset (and I really do hope that, non-skeptically). Maybe if you're persistent now you might get somewhere - although it could take a while; the L1 techs on the forums or wherever are probably not completely tuned into these recent developments.

You could also try being unorthodox, such as for example politely poking random people on GitHub/microsoft (fish emails out of local repo clones :P) - that might find you someone who can figure out a good next hop in the direction of the right department, eg someone might be able to pass your email on to some developer directly. That's always really cool.

You're describing the same issue. OneDrive is only affected because it preloads Office assets.

Other products (e.g. Teams, Office itself) are also affected for the same reason, and spoofing user agents to just officeapps.live.com works around the issue on all of them.

Reply on news.ycombinator.com