8 ms·

I can also see the bug on macOS with Safari 12.0. I find it quite worrying that devs already wrote a lib to fix the issue but didn't fill a bug report to Apple

I can also see the bug on macOS with Safari 12.0. I find it quite worrying that devs already wrote a lib to fix the issue but didn't fill a bug report to Apple and shared it on SO. Anyway, a trendy HN post might be enough to get the attention of some Apple devs and I've pinged a dev just in case: https://twitter.com/ArmandGrillet/status/1042339847384518656 https://twitter.com/ArmandGrillet/status/1042339847384518656

matkinz 8y ago
>I find it quite worrying that devs already wrote a lib to fix the issue but didn't fill a bug report to Apple Why should anybody work for a megacorp for free?
- jsmeaton 8y ago
  This is a strange response. Reporting a bug is likely easier than creating and maintaining a package. It’s also the better solution for users, rather than getting website operators to install yet another lib and then remember to remove it once a fix does land.
  - lolc 8y ago
    If you need the shim anyway to fix it for your users it doesn't particularly matter to you at what point Apple fixes this. The fix will take months to percolate in the best case anyway. It seems you also need an Applie-ID to even report a defect. So to me the unwillingness to help Apple with this is not a strange response. Especially considering Apple made Safari closed-source.
    - jsmeaton 8y ago
      I find the response weird because the commenter had an unwillingness to do free work for a company yet publishes a package that fixes their mistake.
      - lolc 8y ago
        Writing a bug report is work. Writing the shim is work. The bug report doesn't fix the problem right away. The shim fixes the problem right away. Reporting the bug will cause a fix for everybody eventually. Adding the shim will fix it for me. If we want to be nice to Apple - and get rid of the shim eventually - sure, we write a bug report. But if we can fix it before reporting, that gets priority.
- saagarjha 8y ago
  You have a separate comment that decries the use of a polyfill. So what is the solution you’re looking for?
- deleted 8y ago
  [deleted]
saagarjha 8y ago
Works on iOS 12.1’s Safari as well, but that’s to be expected assuming that Apple shipped that without knowledge of this bug.
Cthulhu_ 8y ago
I think there's a lot of people on SO that try and snipe topics like this to boost their own CV.
- abelyao 8y ago
  I am the publisher of SO, that polyfill answer maybe want to get more star on github. I don't know what's means of the ployfill to this big bug.
BonesJustice 8y ago
Does Apple have a halfway decent public issue tracker? I don’t recall ever seeing one, but I’ve never gone out of my way to look for one either.
- jaegerpicker 8y ago
  Yep it's called radar, it's here: https://developer.apple.com/bug-reporting/ https://developer.apple.com/bug-reporting/
  - exikyut 8y ago
    radar isn't public. You need an Apple ID linked to a developer account to view reports.
    - natch 8y ago
      ...which is free and takes about ten seconds to sign up for. You can only view your own reports, but on the other hand they do fix bugs.
      - exikyut 8y ago
        This I did not know. Thanks. Hmm, they must get so many duplicates...
        natch 8y ago
        Yeah they get dupes but they encourage them because they aggregate the information so that new information from one report fleshes out the missing information from other reports.
    - jaegerpicker 8y ago
      It is public, it's free to use and sign up for. The account costs zero dollars to sign up for, so I don't get the complaint.
lolc 8y ago
If I must fix it for my users right now I must use a shim. Letting Apple know about this will probably allow me to remove the shim after months have passed. I can see why the priorities are on the shim here. I also just checked and you need an Apple-ID to report a defect in Safari. Which I for one don't have.
- mnem 8y ago
  I can’t think of any bug system that doesn’t require you to log in to report a bug.
  - lolc 8y ago
    You're right, requiring sign-up is common for these. The only bug tracker I use that doesn't have this barrier is the Debian one.
    - avar 8y ago
      Also the case with any RT-based tracker (Perl core, CPAN), Jira (depending on its configuration, you can create issues via E-Mail), GitLab can also be configured to allow bug creation via an E-Mail address.
- natch 8y ago
  On your last point, it takes a few seconds to create an Apple ID and sign up for a free developer account. Both parts together can be done in less than a minute.
  - Klathmon 8y ago
    And then you have to report the bug yourself as you can't view other people's bug reports, and if they close it as a dupe then you need to ask special permission to view the other bug, and if they grant you access then you can follow it for status updates. And that's if you can even find the right place to report this kind of thing. Some in this thread are pointing to the webkit bugtracker which I've never used, but I have used and had issues closed as dupes in the apple bugtracker with no real info other than it's a dupe of another link I can't view... It's not impossible, but it's a lot more time than I could see having to spend on something like this right now. And I don't think it's fair to criticize someone for not wanting to put that work in, especially if they found a workaround and already posted it somewhere publicly viewable. I'd much rather get a well written bug report from someone that has the time and cares rather than 10 half-assed reports from people who just want to make one so they don't get yelled at or to view the status of another bug.
untog 8y ago
Last I checked Apple's bug reporting system wasn't public. I really wish they'd change that.
- natch 8y ago
  You and many black hat hackers who would love to read through a trove of exploit reports and potentially personal data submitted in uploaded system diagnostics logs.
  - xnyan 8y ago
    Security through obscurity is is not useless, but its not much protection either. There are virtually countless open source projects with public bug tracking, many of which are highly public critical internet facing applications used by millions.
    - donarb 8y ago
      It's not necessarily security through obscurity. It's more of a privacy thing and prevents companies from mining bug reports for information about what types of software competitors are working on. Bug reports also contain code and projects that help Apple find the cause of a bug.
      - TheDong 8y ago
        The simple solution is a two-tiered system. The submitter can check "This report is security sensitive or has confidential information that should not be shared further than necessary to fix the bug." Most projects have this in the form of a default-public bug tracker, and private emails to the developer or security@ mailing list. It's not difficult to have both private and public bugs where the submitter chooses which is appropriate.
        natch 8y ago
        I love it when people think they know better than Apple, and propose simplistic non-solutions as solutions, as if some amazing people at Apple had not already spent countless hours thinking this through at a deep level. The submitter doesn't always know when they are submitting sensitive or confidential information. And that's not going to be fixed any time soon or with any simple solution. There are system diagnostics reports that can be many megabytes and contain potentially confidential information, and it would be entirely unreasonable to expect a user, even a developer user, to know how to trawl through all of these reports with a level of expertise to discern every possible case of leakage. And that's just the personal / private information... which, by the way, Apple from what I've seen seems to strive to keep OUT of the diagnostic reports, but that doesn't mean they are perfect at this. And that doesn't even begin to address the information that might be, totally unknown to the submitter, exploitable in other ways. As far as what other projects have, macOS is a highly complex operating system along with a tightly integrated ecosystem of apps and services, which is designed to, and relied on to, "just work"... while most other systems are either much smaller, or are not maintaining a level of smooth operation and security that can match the "it just works" level of reliability standard that macOS aims for. So maybe the bug reporting systems of all those other projects are appropriate for those other projects, but that doesn't make those systems and their practices appropriate for macOS.
tomxor 8y ago
> I find it quite worrying that devs already wrote a lib to fix the issue but didn't fill a bug report to Apple and shared it on SO. It is worrying... but as someone who has filed my fair share of bug reports to all the major browser projects it's also understandable. Filling good bug reports takes effort, especially for the more obscure ones to produce small and reliable test cases. In my experience only the largest projects have the man power to acknowledge let alone address all bug reports. I abandoned reporting bugs to IE, Edge and Safari long ago because this effort often goes to waste. I get it though, browsers are one of the largest most complex incoherent pieces of software everyone uses today, but that's also why I think only fully open source (well engaged) projects work well in this area. As an aside: This is the same reason I think the browser needs to get simple again (without loosing capability) - RE James Mickens thoughts on this. Then browser diversity and man power becomes a moot point.
- hnruss 8y ago
  I’ve reported a few browser bugs myself, none have been fixed (even years later). I’ll still do it, though, because it may help someone else out someday.
- mh8h 8y ago
  Isn't it this one? https://bugs.webkit.org/show_bug.cgi?id=188794 https://bugs.webkit.org/show_bug.cgi?id=188794
- scarface74 8y ago
  According to the linked SO post, it has already been corrected in a technology preview.
nabakin 8y ago
Looks like its been fixed in the new Safari Preview https://i.imgur.com/A6lm25a.png https://i.imgur.com/A6lm25a.png
tolmasky 8y ago
In theory you absolutely need both, and the library fixes the most pressing issue: that your site might be broken today, and more importantly will remain broken forever, unless the user chooses to upgrade, since Safari does not do automatic over-the-air updates (ala Chrome on desktop) but instead bundles it’s updates with OS versions on mobile, and updates that may or may not be set to automatic on macOS. As such, you should in theory now always have a bug-detect in your code (simple to write, make two identical 2-item arrays, reverse one, check for a difference), and apply the fix if needed.
saudioger 8y ago
You could also just yell into a pillow. Half the time it's just as effective as reporting a bug to Apple without knowing someone there. You can spend a lot of time writing a good bug report for Apple; it's annoying that they don't bother to respond at all a lot of the time.
chrischen 8y ago
Apparently it’s already fixed in Safari dev preview.
saurik 8y ago
As noted by someone else (but only as a new top-level comment), this but was already filed and already fixed on WebKit a week ago and is rdar://problem/43637041.
JangoSteve 8y ago
I don't understand what the worrying part is. The original poster of the SO question was asking a question. They didn't know if it was a bug or them misunderstanding the intended functionality. The subject literally ends with, "is bug or feature?" The people who answered it explain that it's a bug, thereby answering the question, and expand as to why they think it's a bug. One person figured out a patch. The bug was already filed and fixed nearly a month ago but doesn't seem to have been released yet to the current versions of Safari. If there's already a bug filed and marked fixed but you can see that it isn't fixed yet for the people using Safari, and it matters to you, why would sharing it be worrisome? You could argue that the person who answered with a patch didn't know the bug was already filed with Apple, and so they should have sought out how to file it before sharing it. But I think it ignores how intimidating it can be for someone to file an official bug report with a hugely popular piece of software maintained by one of the largest companies in the world. It's even more intimidating if you've done it before and the report you filed ended up being wrong (many maintainers are not very considerate when responding to mistaken bug reports, which can wreak havoc on a developer's self esteem). Meanwhile you have platforms like StackOverflow and Hacker News which vastly lower the bar in terms of needing to be right, since they operate more as conversation facilitators than official registers of legitimate bugs. It's much easier to share what you think you've found with a group of your peers, than it is to go on record telling a group of experts that they've made a mistake in the thing that they're experts on. I don't know if the outcome is worrisome or not, but it definitely seems expected to me... even inevitable. It's the same reason you talk with your friends about how annoyed you are with potholes not being filled before you take your concerns to a town hall meeting. It's a way to refine your thoughts in a low-stakes settings with peers before formalizing an issue to run up the ladder.

matkinz 8y ago

>I find it quite worrying that devs already wrote a lib to fix the issue but didn't fill a bug report to Apple Why should anybody work for a megacorp for free?

jsmeaton 8y ago
This is a strange response. Reporting a bug is likely easier than creating and maintaining a package. It’s also the better solution for users, rather than getting website operators to install yet another lib and then remember to remove it once a fix does land.
- lolc 8y ago
  If you need the shim anyway to fix it for your users it doesn't particularly matter to you at what point Apple fixes this. The fix will take months to percolate in the best case anyway. It seems you also need an Applie-ID to even report a defect. So to me the unwillingness to help Apple with this is not a strange response. Especially considering Apple made Safari closed-source.
  - jsmeaton 8y ago
    I find the response weird because the commenter had an unwillingness to do free work for a company yet publishes a package that fixes their mistake.
    - lolc 8y ago
      Writing a bug report is work. Writing the shim is work. The bug report doesn't fix the problem right away. The shim fixes the problem right away. Reporting the bug will cause a fix for everybody eventually. Adding the shim will fix it for me. If we want to be nice to Apple - and get rid of the shim eventually - sure, we write a bug report. But if we can fix it before reporting, that gets priority.
saagarjha 8y ago
You have a separate comment that decries the use of a polyfill. So what is the solution you’re looking for?
deleted 8y ago
[deleted]

saagarjha 8y ago

Works on iOS 12.1’s Safari as well, but that’s to be expected assuming that Apple shipped that without knowledge of this bug.

Cthulhu_ 8y ago

I think there's a lot of people on SO that try and snipe topics like this to boost their own CV.

abelyao 8y ago
I am the publisher of SO, that polyfill answer maybe want to get more star on github. I don't know what's means of the ployfill to this big bug.

BonesJustice 8y ago

Does Apple have a halfway decent public issue tracker? I don’t recall ever seeing one, but I’ve never gone out of my way to look for one either.

jaegerpicker 8y ago
Yep it's called radar, it's here: https://developer.apple.com/bug-reporting/ https://developer.apple.com/bug-reporting/
- exikyut 8y ago
  radar isn't public. You need an Apple ID linked to a developer account to view reports.
  - natch 8y ago
    ...which is free and takes about ten seconds to sign up for. You can only view your own reports, but on the other hand they do fix bugs.
    - exikyut 8y ago
      This I did not know. Thanks. Hmm, they must get so many duplicates...
      - natch 8y ago
        Yeah they get dupes but they encourage them because they aggregate the information so that new information from one report fleshes out the missing information from other reports.
  - jaegerpicker 8y ago
    It is public, it's free to use and sign up for. The account costs zero dollars to sign up for, so I don't get the complaint.

lolc 8y ago

If I must fix it for my users right now I must use a shim. Letting Apple know about this will probably allow me to remove the shim after months have passed. I can see why the priorities are on the shim here. I also just checked and you need an Apple-ID to report a defect in Safari. Which I for one don't have.

mnem 8y ago
I can’t think of any bug system that doesn’t require you to log in to report a bug.
- lolc 8y ago
  You're right, requiring sign-up is common for these. The only bug tracker I use that doesn't have this barrier is the Debian one.
  - avar 8y ago
    Also the case with any RT-based tracker (Perl core, CPAN), Jira (depending on its configuration, you can create issues via E-Mail), GitLab can also be configured to allow bug creation via an E-Mail address.
natch 8y ago
On your last point, it takes a few seconds to create an Apple ID and sign up for a free developer account. Both parts together can be done in less than a minute.
- Klathmon 8y ago
  And then you have to report the bug yourself as you can't view other people's bug reports, and if they close it as a dupe then you need to ask special permission to view the other bug, and if they grant you access then you can follow it for status updates. And that's if you can even find the right place to report this kind of thing. Some in this thread are pointing to the webkit bugtracker which I've never used, but I have used and had issues closed as dupes in the apple bugtracker with no real info other than it's a dupe of another link I can't view... It's not impossible, but it's a lot more time than I could see having to spend on something like this right now. And I don't think it's fair to criticize someone for not wanting to put that work in, especially if they found a workaround and already posted it somewhere publicly viewable. I'd much rather get a well written bug report from someone that has the time and cares rather than 10 half-assed reports from people who just want to make one so they don't get yelled at or to view the status of another bug.

untog 8y ago

Last I checked Apple's bug reporting system wasn't public. I really wish they'd change that.

natch 8y ago
You and many black hat hackers who would love to read through a trove of exploit reports and potentially personal data submitted in uploaded system diagnostics logs.
- xnyan 8y ago
  Security through obscurity is is not useless, but its not much protection either. There are virtually countless open source projects with public bug tracking, many of which are highly public critical internet facing applications used by millions.
  - donarb 8y ago
    It's not necessarily security through obscurity. It's more of a privacy thing and prevents companies from mining bug reports for information about what types of software competitors are working on. Bug reports also contain code and projects that help Apple find the cause of a bug.
    - TheDong 8y ago
      The simple solution is a two-tiered system. The submitter can check "This report is security sensitive or has confidential information that should not be shared further than necessary to fix the bug." Most projects have this in the form of a default-public bug tracker, and private emails to the developer or security@ mailing list. It's not difficult to have both private and public bugs where the submitter chooses which is appropriate.
      - natch 8y ago
        I love it when people think they know better than Apple, and propose simplistic non-solutions as solutions, as if some amazing people at Apple had not already spent countless hours thinking this through at a deep level. The submitter doesn't always know when they are submitting sensitive or confidential information. And that's not going to be fixed any time soon or with any simple solution. There are system diagnostics reports that can be many megabytes and contain potentially confidential information, and it would be entirely unreasonable to expect a user, even a developer user, to know how to trawl through all of these reports with a level of expertise to discern every possible case of leakage. And that's just the personal / private information... which, by the way, Apple from what I've seen seems to strive to keep OUT of the diagnostic reports, but that doesn't mean they are perfect at this. And that doesn't even begin to address the information that might be, totally unknown to the submitter, exploitable in other ways. As far as what other projects have, macOS is a highly complex operating system along with a tightly integrated ecosystem of apps and services, which is designed to, and relied on to, "just work"... while most other systems are either much smaller, or are not maintaining a level of smooth operation and security that can match the "it just works" level of reliability standard that macOS aims for. So maybe the bug reporting systems of all those other projects are appropriate for those other projects, but that doesn't make those systems and their practices appropriate for macOS.

tomxor 8y ago

> I find it quite worrying that devs already wrote a lib to fix the issue but didn't fill a bug report to Apple and shared it on SO. It is worrying... but as someone who has filed my fair share of bug reports to all the major browser projects it's also understandable. Filling good bug reports takes effort, especially for the more obscure ones to produce small and reliable test cases. In my experience only the largest projects have the man power to acknowledge let alone address all bug reports. I abandoned reporting bugs to IE, Edge and Safari long ago because this effort often goes to waste. I get it though, browsers are one of the largest most complex incoherent pieces of software everyone uses today, but that's also why I think only fully open source (well engaged) projects work well in this area. As an aside: This is the same reason I think the browser needs to get simple again (without loosing capability) - RE James Mickens thoughts on this. Then browser diversity and man power becomes a moot point.

hnruss 8y ago
I’ve reported a few browser bugs myself, none have been fixed (even years later). I’ll still do it, though, because it may help someone else out someday.
mh8h 8y ago
Isn't it this one? https://bugs.webkit.org/show_bug.cgi?id=188794 https://bugs.webkit.org/show_bug.cgi?id=188794
scarface74 8y ago
According to the linked SO post, it has already been corrected in a technology preview.

nabakin 8y ago

Looks like its been fixed in the new Safari Preview https://i.imgur.com/A6lm25a.png https://i.imgur.com/A6lm25a.png

tolmasky 8y ago

In theory you absolutely need both, and the library fixes the most pressing issue: that your site might be broken today, and more importantly will remain broken forever, unless the user chooses to upgrade, since Safari does not do automatic over-the-air updates (ala Chrome on desktop) but instead bundles it’s updates with OS versions on mobile, and updates that may or may not be set to automatic on macOS. As such, you should in theory now always have a bug-detect in your code (simple to write, make two identical 2-item arrays, reverse one, check for a difference), and apply the fix if needed.

saudioger 8y ago

You could also just yell into a pillow. Half the time it's just as effective as reporting a bug to Apple without knowing someone there. You can spend a lot of time writing a good bug report for Apple; it's annoying that they don't bother to respond at all a lot of the time.

chrischen 8y ago

Apparently it’s already fixed in Safari dev preview.

saurik 8y ago

As noted by someone else (but only as a new top-level comment), this but was already filed and already fixed on WebKit a week ago and is rdar://problem/43637041.

JangoSteve 8y ago

I don't understand what the worrying part is. The original poster of the SO question was asking a question. They didn't know if it was a bug or them misunderstanding the intended functionality. The subject literally ends with, "is bug or feature?" The people who answered it explain that it's a bug, thereby answering the question, and expand as to why they think it's a bug. One person figured out a patch. The bug was already filed and fixed nearly a month ago but doesn't seem to have been released yet to the current versions of Safari. If there's already a bug filed and marked fixed but you can see that it isn't fixed yet for the people using Safari, and it matters to you, why would sharing it be worrisome? You could argue that the person who answered with a patch didn't know the bug was already filed with Apple, and so they should have sought out how to file it before sharing it. But I think it ignores how intimidating it can be for someone to file an official bug report with a hugely popular piece of software maintained by one of the largest companies in the world. It's even more intimidating if you've done it before and the report you filed ended up being wrong (many maintainers are not very considerate when responding to mistaken bug reports, which can wreak havoc on a developer's self esteem). Meanwhile you have platforms like StackOverflow and Hacker News which vastly lower the bar in terms of needing to be right, since they operate more as conversation facilitators than official registers of legitimate bugs. It's much easier to share what you think you've found with a group of your peers, than it is to go on record telling a group of experts that they've made a mistake in the thing that they're experts on. I don't know if the outcome is worrisome or not, but it definitely seems expected to me... even inevitable. It's the same reason you talk with your friends about how annoyed you are with potholes not being filled before you take your concerns to a town hall meeting. It's a way to refine your thoughts in a low-stakes settings with peers before formalizing an issue to run up the ladder.