[acoard]

You're not wrong, but in practice I'd imagine >99% of bugs are in the rendering / webkit layer, not in the OS integration layer.

Sure, if you're making a plugin that plays with bookmarks or 'Read Later', you'd likely run afoul of the issues you mention. But most web devs are concerned just about browser compatibility of rendering their web-app. In this context, as long as web page rendering and JS engine is identical between OS' it's fine.

[acdha]

This very much depends on the bugs. In the past I've found many bugs in text rendering (especially related to non-English text[1][2]), layering (inconstent opacity), audio and video playback, etc. which were dependent on the combination of browser, operating system, and, in some cases, hardware. The general trend has been for browsers like Chrome and Firefox to take over more responsibility but that's not what Apple has done in Safari so it looks like a lot more work to say they should duplicate OS functionality to make it easier for Windows-only web developers to test with Safari.

1. https://chris.improbable.org/experiments/browser/combining-h...

2. https://chris.improbable.org/experiments/browser/javanese-te...

[derefr]

Rendering issues are OS issues too. For example, Safari's font rendering depends on the particulars of macOS/iOS's font-rendering framework. Safari on Windows would presumably use Windows' font-rendering framework, with drastically different results, due to the different frameworks supporting different subsets of e.g. ligature-pair width hinting or hyphenation, thereby causing text to wrap in different places, such that the layout at a given font size + viewport size on Windows wouldn't be predictive of the layout at the same font size + viewport size on macOS. (Which is not even to mention the fonts you'd have by default on Windows and not by default on macOS, that would interfere with the font family cascade, and yet couldn't be suppressed from the cascade because some macOS systems do have them.)

Or, for that matter, there could be certain exposed -webkit CSS selectors that are really just features of some or another macOS rendering-layer framework, with no Windows equivalent — the same way that IE's ancient CSS "filters" were really just exposed DirectX features (e.g. filter: progid:DXImageTransform.Microsoft.blur). For these cases, testing on "Safari on Windows" would essentially just get you what testing in Chrome on Windows already gets you (unless Apple created an entire software renderer that brings in all of macOS's Quartz and all its subsidiary libraries as a big ol' polyfill.)

The point at which Safari is guaranteed to work like it does on macOS, is the point at which you're bringing in a polyfill consisting of 99% of macOS's frameworks. May as well bring in the last 1% as well, and call it a VM. (Ideally a thin-as-possible paravirtualized VM where the display driver is written to directly make DirectX calls, etc. — but VM client software is already pretty good at providing these sorts of drivers.)