7 ms·

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 w

by ebang4 10y ago

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.

iliketosleep 10y ago
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.
- annnnd 10y ago
  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.
  - Karlozkiller 10y ago
    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)
  - greenzebra 10y ago
    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 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.
    - annnnd 10y ago
      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.
  - deadbunny 10y ago
    > 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.
  - josteink 10y ago
    > 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.
    - annnnd 10y ago
      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.
  - ldev 10y ago
    > 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.
  - ams6110 10y ago
    > 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.
    - vetinari 10y ago
      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.
    - annnnd 10y ago
      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.
i336_ 10y ago
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_prefetching_FAQ https://developer.mozilla.org/en-US/docs/Web/HTTP/Link_prefe...
- ebang4 10y ago
  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 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
  - i336_ 10y ago
    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
faragon 10y ago
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.
- deleted 10y ago
  [deleted]
- alexval 10y ago
  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.
  - faragon 10y ago
    So engineers at "New Microsoft" read Hacker News, but don't use "New Microsoft" products on Linux.
    - pmilot 10y ago
      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.
      - faragon 10y ago
        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.
dim13 10y ago
> 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.
- column 10y ago
  Read his post again
- NoGravitas 10y ago
  Fixed in test, not in production yet.
EJTH 10y ago
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) ?
hd4 10y ago
Going forward, do you plan to test your code on Linux as a primary platform?
m0skit0 10y ago
I'm 100% sure it was not intentional!
jMyles 10y ago
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?
- anonbanker 10y ago
  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.
fjdlwlv 10y ago
Why was the issue ignored for several months, and then fixed in one day when it hit the front page of HN?

by ebang4 10y ago

iliketosleep 10y ago

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.

annnnd 10y ago
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.
- Karlozkiller 10y ago
  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)
- greenzebra 10y ago
  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 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.
  - annnnd 10y ago
    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.
- deadbunny 10y ago
  > 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.
- josteink 10y ago
  > 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.
  - annnnd 10y ago
    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.
- ldev 10y ago
  > 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.
- ams6110 10y ago
  > 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.
  - vetinari 10y ago
    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.
  - annnnd 10y ago
    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.

i336_ 10y ago

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_prefetching_FAQ https://developer.mozilla.org/en-US/docs/Web/HTTP/Link_prefe...

ebang4 10y ago
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 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
- i336_ 10y ago
  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

faragon 10y ago

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.

deleted 10y ago
[deleted]
alexval 10y ago
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.
- faragon 10y ago
  So engineers at "New Microsoft" read Hacker News, but don't use "New Microsoft" products on Linux.
  - pmilot 10y ago
    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.
    - faragon 10y ago
      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.

dim13 10y ago

> 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.

column 10y ago
Read his post again
NoGravitas 10y ago
Fixed in test, not in production yet.

EJTH 10y ago

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) ?

hd4 10y ago

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

m0skit0 10y ago

I'm 100% sure it was not intentional!

jMyles 10y ago

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?

anonbanker 10y ago
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.

fjdlwlv 10y ago

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