Hacker News Reader

Comment by ebang4 | Hacker News Reader

Hi everyone, this is Edgar from the OneDrive team. We know that some users may have experienced difficulty accessing OneDrive for Business on Linux. The issue was resolved as of Tue, March 22nd 3pm PST.

We identified that StaticLoad.aspx, a page that prefetches resources in the background for Office online apps was using the link prefetching browser mechanism only for certain platforms (iOS, Chrome OS, Mac, Windows), but for Linux it was falling back to a less efficient technique that was causing the issue. Rest assured that this was not intentional. It was an oversight.

The prefetching optimization was disabled, and it will be enabled again soon after an update for StaticLoad.aspx has been tested on Linux and released.

We apologize for the inconvenience this may have caused.

View on HN

Thanks for popping in here to clarify this personally, thanks very much for the imminent Linux-specific fix, and thanks for the clarification that this was an oversight :)

I'm curious about the "less efficient technique" you referred to. Insight into the technical context around the goal being achieved may be very interesting to other Web developers looking to make their JavaScript applications more efficient and responsive.

A lot of people are also likely to be very interested to learn what solution you use to fix this for Linux as well.

As an aside, link prefetching caught my eye - it's an interesting mechanism that works via <link> or <meta> tag, or via HTTP headers: https://developer.mozilla.org/en-US/docs/Web/HTTP/Link_prefe...

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.

So for the "New Microsoft" releasing a bug fix for a "bug" affecting customers using Linux for more than 3 months it just required to be popular at Hacker News and Reddit.

Sometimes at a large company feedback from support and those customer forms doesn't make it all the way back to the engineers. The engineers read hacker news. As soon as they saw this it makes sense that they fixed it.

Seems like the pipeline for customer feedback could be improved.

So engineers at "New Microsoft" read Hacker News, but don't use "New Microsoft" products on Linux.

It may sound farfetched to you, but I assure you that some people who read Hacker News regularly don't actually use Linux on a day-to-day basis.

Sure. That was my point: the "New Microsoft" is not using Linux, or don't {care about | want} their customers using "New Microsoft" products on Linux.

Kudos for fixing the issue. I do question whether it was originally tested throughly on Linux in the first place, otherwise it's hard to see how such a major bug could have crept in.

This! As a Linux user I don't really care if someone is neglecting my platform of choice or purposefully sabotaging it, I'll just move on in any case. Not performing testing on Linux is inexcusable in my book in this day and age.

It seems like a bad idea to check for capabilities by parsing user agent string anyway - I though we all figured that out about 20 years ago? JavaScript allows web page to check for capabilities on-the-fly, so there really is no excuse for whitelists.

And if they would have a pure JavaScript solution people who block JavaScript would start complaining instead no? Of course you could have JavaScript as a primary solution and then fall back on the other options.

Anyone can make a mistake, the real test is whether they change their ways to be less error prone. (With proper testing of Linux platforms too)

I am curious how @annnd detects whether link prefetching is supported by a browser in js on-the-fly (reliably and in a performant way) http://caniuse.com/#feat=link-rel-prefetch. There are many capabilities you can quickly detect, but for that one I can't think of a performant way. Test your solution with Safari on a Mac, which should return false.

I haven't tried detecting whether link prefetching is supported by a browser yet. Not that I think it should even be detected, because those are hints to the browser. If you need to depend on them there is something else wrong with the way you design your apps.

But if you still insist you need it, I don't think detection should be that difficult. When user comes to the page for the first time you put a hidden link somewhere with prefetch turned on. Then you ask server if the page has been accessed. And because you only make this check once (for instance on login page while the user is typing) it is performant enough.

Is it easier to whitelist? Sure. But we have seen here how reliable whitelisting is.

> I'll just move on in any case.

Unfortunately not all of us have that option. I'm currently trying to figure out an issue with TFS which means I can't do anything with a PR once it's been raised if I use a browser in Linux. After seeing this thread I think I'll be switching the user agent and see if that fixes it.

> It seems like a bad idea to check for capabilities by parsing user agent string anyway

In theory yes. But for some cases it's just not realistic to do feature-detection, and then you move on to the second best option you have.

I'm pretty sure we'll have user-agent related bugs for quite a time to come.

Sure, but that is for some very limited cases. And even then you should generally check for browser and its version, not the OS. Browser makers go to great lengths to make browsers run identically on all supported platforms.

> Not performing testing on Linux is inexcusable in my book in this day and age.

No, wasting time for two open minded users instead of working for 99,999% users is inexcusable.

> Not performing testing on Linux is inexcusable in my book in this day and age.

1. There are probably more IE7 users hitting OneDrive than Linux users of all distros combined. Should the fact that there are some users of a platform obligate MS to support it?

2. If you're running Linux on the desktop, you've made a decision to eschew all the major commercial software/OS vendors (particularly Microsoft and Apple). Why should you then expect Microsoft to bend over backwards to support your idiosyncracy? Why do you care?

I run OpenBSD on my desktop. I can't run Microsoft stuff. Even Outlook Web won't load unless I spoof my user agent. I don't care.

It is actually problem for Microsoft/Apple.

The percentage between $PLATFORM users generally and $PLATFORM users using your product may or may be not correlated. It may happen, that then first percentage will rise but the second will not - you are making it difficult for them, so why bother - and you will miss it.

You might fix the software later, but that's the easy part. The more difficult part is to fix your reputation and users habits. They already have opinion of you and found alternatives that work for them. The Thank you, I go back to Google Apps suite. response is a perfect example of this.

I don't care either, FWIW.I haven't used OneDrive yet and I probably never will. But the reason I will not use it is exactly this - I know I will always be unwanted customer in their eyes. And I don't trust them not to throw me under the bus if they feel like it. I should probably say "...is inexcusable to me in this...". Thought it was obvious.

I'm reluctant to belabor the point, but I must say that, at first blush, this doesn't seem to add up.

Content prefetching? Sounds good (if you are prefetching the right content of course).

Checking the user-agent and doing prefetching only on that basis? I can think of no reason to do such a thing.

If this was not intentional, can you clarify the reason that your team engineered such a strange and unusual solution?

It's depressing that your question is downvoted to grey. I consider it a sign that people think it's better to be a coincidence theorist rather than a conspiracy theorist.

> The issue was resolved as of Tue, March 22nd 3pm PST.

Just tried (Thu Mar 23 10:25:18 CET 2017) -- the bug is still here.

Read his post again

Fixed in test, not in production yet.

Going forward, do you plan to test your code on Linux as a primary platform?

I'm 100% sure it was not intentional!

Why do you need to look at the OS in the UA string in order to do this? Seems like you are doing it wrong (tm) ?

Why was the issue ignored for several months, and then fixed in one day when it hit the front page of HN?

Reply on news.ycombinator.com