Skip to content

[web] Only create one <style> for SelectableRegion #161682

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

Merged
merged 11 commits into from
Feb 5, 2025

Conversation

mdebbar
Copy link
Contributor

@mdebbar mdebbar commented Jan 15, 2025

We used to create and insert a new <style> element for each SelectableRegion widget. That's unnecessary. All we need is one <style> element that contains the style sheets that we want to apply.

Most of this PR is re-working the tests to be able to check that the issue is actually fixed.

Fixes #161519

@github-actions github-actions bot added the framework flutter/packages/flutter repository. See also f: labels. label Jan 15, 2025
@mdebbar mdebbar requested a review from ditman January 22, 2025 19:49
Copy link
Member

@ditman ditman left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This LGTM, I left some comments but I don't think they're blocking.

Comment on lines +113 to +116
// Create css style for _kClassName.
final web.HTMLStyleElement styleElement =
web.document.createElement('style') as web.HTMLStyleElement;
web.document.head!.append(styleElement as JSAny);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would it make sense to give a uniqueID to this styleElement, so it can be re-accessed without caching it in the element (it's supposedly a stateless widget?)

I'm not sure what the "guarantees" are that the stateless widget won't be re-created at any time (causing the code to attempt to re-register the view?)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The registration methods and variables are all static, so there's only a single registration call across all widgets.

sheet.insertRule(_kClassRule, 0);
sheet.insertRule(_kClassSelectionRule, 1);

_registerViewFactory(_viewType, (int viewId, {Object? params}) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could this be reimplemented with the fromTag constructor, instead of having to register the view? That way we wouldn't need to keep a flag for the factory being registered or not.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes it could, and I would like that of course :)

But I'll keep this PR focused on fixing the issue at hand. Refactors can come in a follow up PR.

Comment on lines +97 to +102
if (view == null) {
throw PlatformException(
code: 'error',
message: 'Trying to dispose a platform view with unknown id: $id',
);
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe replace these comparisons with null by asserts? The code of this helper would be simplified quite a bit!

assert(view != null, 'Trying to dispose a platform view with unknowin id: $id');?

(Or are we expecting a PlatformException elsewhere in these tests?)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think we are "expecting" a PlatformException in tests, but the real platform channel throws a PlatformException when an error occurs. So this "fake" registry should throw the same type of exception as the real registry.

@mdebbar mdebbar added the autosubmit Merge PR when tree becomes green via auto submit App label Feb 5, 2025
@auto-submit auto-submit bot added this pull request to the merge queue Feb 5, 2025
Merged via the queue into flutter:master with commit 996badc Feb 5, 2025
77 checks passed
@flutter-dashboard flutter-dashboard bot removed the autosubmit Merge PR when tree becomes green via auto submit App label Feb 5, 2025
engine-flutter-autoroll added a commit to engine-flutter-autoroll/packages that referenced this pull request Feb 6, 2025
engine-flutter-autoroll added a commit to engine-flutter-autoroll/packages that referenced this pull request Feb 6, 2025
engine-flutter-autoroll added a commit to engine-flutter-autoroll/packages that referenced this pull request Feb 6, 2025
engine-flutter-autoroll added a commit to engine-flutter-autoroll/packages that referenced this pull request Feb 6, 2025
@mdebbar mdebbar deleted the fix_infinite_styles branch February 6, 2025 19:36
engine-flutter-autoroll added a commit to engine-flutter-autoroll/packages that referenced this pull request Feb 7, 2025
engine-flutter-autoroll added a commit to engine-flutter-autoroll/packages that referenced this pull request Feb 7, 2025
engine-flutter-autoroll added a commit to engine-flutter-autoroll/packages that referenced this pull request Feb 7, 2025
engine-flutter-autoroll added a commit to engine-flutter-autoroll/packages that referenced this pull request Feb 8, 2025
engine-flutter-autoroll added a commit to engine-flutter-autoroll/packages that referenced this pull request Feb 8, 2025
engine-flutter-autoroll added a commit to engine-flutter-autoroll/packages that referenced this pull request Feb 9, 2025
engine-flutter-autoroll added a commit to engine-flutter-autoroll/packages that referenced this pull request Feb 9, 2025
engine-flutter-autoroll added a commit to engine-flutter-autoroll/packages that referenced this pull request Feb 10, 2025
engine-flutter-autoroll added a commit to engine-flutter-autoroll/packages that referenced this pull request Feb 10, 2025
engine-flutter-autoroll added a commit to engine-flutter-autoroll/packages that referenced this pull request Feb 10, 2025
engine-flutter-autoroll added a commit to engine-flutter-autoroll/packages that referenced this pull request Feb 10, 2025
engine-flutter-autoroll added a commit to engine-flutter-autoroll/packages that referenced this pull request Feb 10, 2025
engine-flutter-autoroll added a commit to engine-flutter-autoroll/packages that referenced this pull request Feb 11, 2025
engine-flutter-autoroll added a commit to engine-flutter-autoroll/packages that referenced this pull request Feb 11, 2025
engine-flutter-autoroll added a commit to engine-flutter-autoroll/packages that referenced this pull request Feb 11, 2025
engine-flutter-autoroll added a commit to engine-flutter-autoroll/packages that referenced this pull request Feb 11, 2025
engine-flutter-autoroll added a commit to engine-flutter-autoroll/packages that referenced this pull request Feb 11, 2025
engine-flutter-autoroll added a commit to engine-flutter-autoroll/packages that referenced this pull request May 20, 2025
engine-flutter-autoroll added a commit to engine-flutter-autoroll/packages that referenced this pull request May 20, 2025
engine-flutter-autoroll added a commit to engine-flutter-autoroll/packages that referenced this pull request May 21, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
framework flutter/packages/flutter repository. See also f: labels.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Flutter Web generating infinite <style> tags
2 participants