Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Alternate browser engines on iOS must be able to bring their own rendering architecture #11

Open
RByers opened this issue Feb 4, 2024 · 0 comments
Labels
Platform: iOS Priority: 0 - Essential Highest level priority, a must have, required for Browsers, Web Apps or functional competition Status: Open Open for discussion Support: Google Support: Open Web Advocacy To: Apple Requests made to Apple

Comments

@RByers
Copy link

RByers commented Feb 4, 2024

Description

Apple's Browser Engine Kit documentation says:

To correctly render CSS and manipulate the Javascript DOM, your browser app needs to integrate closely with UIKit and customize the way it handles many low-level user interface events. Use view classes in BrowserEngineKit to handle scrolling, drag interactions, and the context menu in your browser app.

It's not entirely clear, but this seems to imply that existing browser rendering engines must be re-architected to fit the UIKit rendering model. Chromium has a large and sophisticated rendering architecture which is designed to be platform-agnostic, rather than rely on operating-system-specific details such as the OS compositing architecture. As such, complex behaviour like scrolling is implemented nearly identically across all non-iOS Chrome platforms including Windows, MacOS, Android, Linux and ChromeOS. Using an operating-system provided scrolling / compositing architecture is infeasible for Chromium both because of the huge engineering expense and also because it would result in a worse product in some ways.

For example, the CSS specifications define a very complex set of stacking rules that determine how elements layer on top of each other. Chrome and Firefox have worked hard to implement this faithfully, while WebKit still has bugs which are probably due to limitations in Apple's UIKit system. For this test page, Chrome and Firefox render it correctly on MacOS as follows:
image
But Safari incorrectly clips the green box to be contained by the black scrolling rectangle:
image

It should be possible to implement a 100% CSS-spec-compliant rendering engine on iOS in the EU.

Outcome

Apple's Browser Engine Kit documentation should be clarified to indicate that use of UIKit components like BEScrollView are optional, or can be easily integrated into an existing browser rendering architecture. It's not yet clear if iOS contains all the functionality necessary for alternate browser engines to use their own rendering architecture without loss of full fidelity in functionality like text selection, accessibility, scrolling and dragging. But to the extent such functionality is found to be missing, iOS should provide the necessary lower-level hooks to enable it.

@RByers RByers added the Status: Triage A new issue that has been added to the system, needs to be checked by moderators for scope/quality label Feb 4, 2024
@mtom55 mtom55 added Priority: 0 - Essential Highest level priority, a must have, required for Browsers, Web Apps or functional competition Status: Open Open for discussion Support: Google Support: Open Web Advocacy To: Apple Requests made to Apple Platform: iOS and removed Status: Triage A new issue that has been added to the system, needs to be checked by moderators for scope/quality labels Feb 4, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Platform: iOS Priority: 0 - Essential Highest level priority, a must have, required for Browsers, Web Apps or functional competition Status: Open Open for discussion Support: Google Support: Open Web Advocacy To: Apple Requests made to Apple
Projects
None yet
Development

No branches or pull requests

2 participants