[flagged]
What sites trigger this? Have been using Safari for years and haven’t encountered such a bug.
The Safari bug that never was (2022)
71–80 of 94 posts
Re: The Safari bug that never was (2022)
#72[flagged]
My impression is that the Safari team is just very small. They are often more quirky than other browsers, and they lag in features (but not nearly so badly as IE used to). On the other hand they've brought some very welcome improvements: the :has selector and container queries being the standout ones in recent times. And their engine is more power efficient and often faster than anyone elses. EDIT: I would add: 90% s…
caniuse... It's like yeah it supports animations and then fails to mention everything with a transform flickers.
Or how the introduction of rubber band scrolling completely broke fixed positional elements but "safari supports position fixed".
I had a feature which shown an element if the browser UI was expanded and you weren't using the full potential height of the browser... So it tells you to swipe up to trigger a page scroll which minimises the UI. 15.6 gets released and the whole thing breaks and basically becomes impossible now.
Or how flex with 100% height is only not inherited in safari.
It's missing alot of footnotes for a myriad of issues.
Whenever it mentions support for anything new you have to take it with a fist full of salt.
I'm sorry, 90% was an exaggeration and it's probably closer to 70%
Re: The Safari bug that never was (2022)
#73Earlier quoted context omitted.
> all the work happens in the public bug database. Code review, patch dev, etc for webkit occurs in bugzilla. What about discussion? Do you claim there is no private discussion among Apple engineers about WebKit bugs that have been put "InRadar"? I see a lot of WebKit bugs that have no discussion whatsoever and just seem to arrive ex nihilo from Radar. You wonder what the reasoning or explanation is for a certain cod…
> Do you claim there is no private discussion among Apple engineers about WebKit bugs that have been put "InRadar"? Open source bugs will have private/non-public conversations (whether it's in person, or on slack, or on a seperate issue tracker) all the time. That's not abnormal or all that damning.
[deleted]
Re: The Safari bug that never was (2022)
#74Earlier quoted context omitted.
Webkit bugs do not get transferred to radar to be worked on. Assuming the bug is actually in webkit (eg not a bug in the safari app or an underlying system framework), all the work happens in the public bug database. Code review, patch dev, etc for webkit occurs in bugzilla. There are many reasons for linking bugzilla bugs to radar, but the big ones are scheduling, other project dependencies inside Apple, security re…
> all the work happens in the public bug database. Code review, patch dev, etc for webkit occurs in bugzilla. What about discussion? Do you claim there is no private discussion among Apple engineers about WebKit bugs that have been put "InRadar"? I see a lot of WebKit bugs that have no discussion whatsoever and just seem to arrive ex nihilo from Radar. You wonder what the reasoning or explanation is for a certain cod…
> What about discussion?
Is achieved by talking among each other, or simply by knowing how to fix/implement the feature (not every bug requires any discussion at all). Either in person (which would be inherently "private" as you say), or irc historically - I'm unsure whether irc is still significant as I recall free node dying off or something a few years back?
> Do you claim there is no private discussion among Apple engineers about WebKit bugs that have been put "InRadar"?
No, I'm saying your claim that "The funny thing though is that Apple still sends WebKit bugs into Radar to work on them:" is nonsense. The reason that bugs are cloned to radar is so that they can be tracked for releases. I think you have decided that any time you don't see discussion in b.w.o it means discussion there must be discussion in radar, and that's false. The reality is that most bug fix/feature implementation doesn't require discussion during development, actual recorded discussion happens during review as that systematically results in recording the exchanges.
> I see a lot of WebKit bugs that have no discussion whatsoever and just seem to arrive ex nihilo from Radar.
Again, I think you grossly overestimate the amount of recorded "discussion" that goes with a bug.
> You wonder what the reasoning or explanation is for a certain code change, and you'll find absolutely nothing about it in the Bugzilla.
For many there's not anything in radar either, because many (most?) bugs you see are created to track reviewing the change, and don't exist before the review process. The lack of explanation is typically because the engineers working on changes have the context for why a change is needed, so don't include an explanation.
Re: The Safari bug that never was (2022)
#75Earlier quoted context omitted.
> all the work happens in the public bug database. Code review, patch dev, etc for webkit occurs in bugzilla. What about discussion? Do you claim there is no private discussion among Apple engineers about WebKit bugs that have been put "InRadar"? I see a lot of WebKit bugs that have no discussion whatsoever and just seem to arrive ex nihilo from Radar. You wonder what the reasoning or explanation is for a certain cod…
> What about discussion? Is achieved by talking among each other, or simply by knowing how to fix/implement the feature (not every bug requires any discussion at all). Either in person (which would be inherently "private" as you say), or irc historically - I'm unsure whether irc is still significant as I recall free node dying off or something a few years back? > Do you claim there is no private discussion among Appl…
> I recall free node dying off or something a few years back?
Yeah, a kind of hostile takeover occurred, which the IRC community did not appreciate.
> Again, I think you grossly overestimate the amount of recorded "discussion" that goes with a bug.
Perhaps so. Seems a bit odd to me though. And a bit lonely :-)
> The lack of explanation is typically because the engineers working on changes have the context for why a change is needed, so don't include an explanation.
Well, I think it's worth noting that this is not very helpful to outsiders who are looking at and working with the code of an open source project.
Even in my closed source self owned projects, I like to provide useful context to my future self. ;-)
Re: The Safari bug that never was (2022)
#76Earlier quoted context omitted.
My impression is that the Safari team is just very small. They are often more quirky than other browsers, and they lag in features (but not nearly so badly as IE used to). On the other hand they've brought some very welcome improvements: the :has selector and container queries being the standout ones in recent times. And their engine is more power efficient and often faster than anyone elses. EDIT: I would add: 90% s…
caniuse... It's like yeah it supports animations and then fails to mention everything with a transform flickers. Or how the introduction of rubber band scrolling completely broke fixed positional elements but "safari supports position fixed". I had a feature which shown an element if the browser UI was expanded and you weren't using the full potential height of the browser... So it tells you to swipe up to trigger a…
That's also my experience with Safari, not much is really "supported", most of the features are "supported, conditions may apply".
And i'm not talking about cutting edge features, there's still zIndex bugs and click event bugs on safari mobile for example.
Re: The Safari bug that never was (2022)
#77These types of text metrics bugs show up in my code over and over and over and over again. I keep making them! When I was working on the icon view in Finder, icon layout, multi-line icon labels, additional info text and anything else using metrics would constantly be in danger of collapsing. Was this because I was a sloppy coder? Maybe... but the whole stack is so finicky and brittle and filled with some many special…
Text layout is just hard. There’s a lot of history you need to encode as rules, and you end up with a very complicated system that is hard to abstract because there are circular dependencies all over the place. This bug was because the size of the container depends on the text, whose layout depends on the container. Text just wouldn’t look “right” if we skipped it.
It’s as “human” a problem as dates and time, probably worse! Your best bet is to use libraries to avoid the whole problem, but that means delegating all layout which might not be possible.
Re: The Safari bug that never was (2022)
#78Let's not use "(previous year)" on titles when it's hasn't even been a week since the new year started, at least January should be free of "(2022)" tags, this early in the year those are just noise.
Re: The Safari bug that never was (2022)
#79Earlier quoted context omitted.
> What about discussion? Is achieved by talking among each other, or simply by knowing how to fix/implement the feature (not every bug requires any discussion at all). Either in person (which would be inherently "private" as you say), or irc historically - I'm unsure whether irc is still significant as I recall free node dying off or something a few years back? > Do you claim there is no private discussion among Appl…
> I recall free node dying off or something a few years back? Yeah, a kind of hostile takeover occurred, which the IRC community did not appreciate. > Again, I think you grossly overestimate the amount of recorded "discussion" that goes with a bug. Perhaps so. Seems a bit odd to me though. And a bit lonely :-) > The lack of explanation is typically because the engineers working on changes have the context for why a c…
> Perhaps so. Seems a bit odd to me though. And a bit lonely :-)
People communicate in IRC (or a public slack now based on another comment?), in person, or in email. So when needed communication happens, it's just generally back and forth commentary in a bug is not a particularly good or efficient way to discuss implementation of bug fixes, features, etc.
> Well, I think it's worth noting that this is not very helpful to outsiders who are looking at and working with the code of an open source project.
Because it's a bug tracker being used to track bug fixes, not a tool for communicating with arbitrary people not involved in the project? I don't mean to be glib, but for WK at least that's just not what the bug trackers are used for.
> Even in my closed source self owned projects, I like to provide useful context to my future self.
In the bug report or in the code? Generally IME when code does things that are odd the explanation of that oddness is in the code (assuming not self explanatory) not the bug tracker.
It also depends on the bug itself, bug fixes you'd normally be able to see why a change was made (if not obvious from the title/description) is the attached test cases.
Re: The Safari bug that never was (2022)
#80Earlier quoted context omitted.
> Even if the work is being done publicly, it still needs to be tracked and project-managed internally by the team. bugs.webkit.org is literally a bug tracker. The only relevant difference between Radar and WebKit Bugzilla is private vs. public.
No. B.w.o has no release tracking, it has no ability to track dependencies on other Apple projects, etc B.w.o is where bug fixes happen, no more. Code dev and review has to happen in b.w.o by the webkit community rules, not radar.
That’s now on GitHub.