Material-components-web-components: Foundation event listeners from individual simple icon buttons on the main body node....

[cintaccs]

* PLEASE READ THIS BEFORE FILING AN ISSUE *

I'm submitting a:

• [X ] bug report
• [ ] feature request

What OS are you using?
Windows 10, MWC 0.13

What browser(s) is this bug affecting:
Latest Chrome

Current behavior:
when using
import '@material/mwc-icon-button';

then for each use of <mwc-icon-button icon="list"></mwc-icon-button>

I see resize events listener on the body of the main document - referring to foundation - ripple. Can that really be? should a simple button be listening on the body node for resize....

Expected behavior:
no side-effects should be expected from using mwc components. They should embed their own handling and events.

Steps to reproduce:

[asyncLiz]

Thanks for the issue! I've filed https://github.com/material-components/material-components-web/issues/5578 to fix this in MDC. We only need the resize listener if the unbounded ripple is not a perfect circle, so we shouldn't add it for things like icon button.

[cintaccs]

shouldn't all ripple internal handling stay inside the shadow DOM of the component in any case. I.e. all events fired regarding floating labels, ripples and own component resizing should not bubble outside of the components for most of your stuff....

[asyncLiz]

It depends. For bounded ripples (stay within the container, like a button) and unbounded perfect circle ripples (like icon buttons), yes.

For unbounded oblong ripples, their shape may change as the component width or height changes. ResizeObserver would be a great use case for this, but it's not supported in all browsers. The window's resize event is the next best thing.

[cintaccs]

thanks for the additional info! Make sense! I have seen that the circle ripples of icon buttons actually do not respect the list item density in the more condensed modes ... so I can follow what you mean although I think that CSS classes would be a better fit than event observers. ... but that is just a "feel". In general I see many issues reported here with too many fired events - and I had a crazy example myself on dialog::opened listener too that made me stop using that event completely for the same reason. IMO I think resizing and most of the show hide logic should be done with conditional css. Having the web components and lit class map features should give extra control but still avoid events fired for pure styling.... ..maybe it is just me...

[asyncLiz]

Pure CSS would be nice, and we usually try to aim for that. Unfortunately the logic behind ripples is too complicated for a pure CSS solution.

[cintaccs]

Thanks for the feedback! I see your point.
However... as the Text fields have a .layout() method that needs to be called for the floating notches to adjust on re-entering a DOM node that previously had been instantiated - maybe there could be a general method that could be called from a window change resize event instead of a listener for each little icon all over the place. I doubt those listeners will survive tab pages of content with mwc-icons being switched quickly... actually that is the only way I can get the notches to behave nicely on such a tabbed scenario. Initially init on construction - and if exist - then .layout(). I guess the icons would work similar.

btw isn't there a way to create a circle with css ... and animate the size of it on hover / activate... I understand that the center of the circle would have to be in the middle of the element... hmmm... if I create one I will share and let you know... :-)

[asyncLiz]

The upstream fix will ensure that there are no window resize listeners for icon buttons.

It's unfortunately not just "creating a circle" for CSS. There's a lot more that goes into it for both bounded and unbounded ripples that relies on the position of the element and where things were clicked for bounded ripples.

[cintaccs]

Thanks for your support on this! Much appreciated! I am not sure whether I can use "upstream"... I have problems getting beyond "5.0.0-canary.0d42ee650.0" because of some SCSS rules that I have tried to investigate but can't resolve. I understand we are not supposed to use canary builds... but there are so many changes since 3 month ago and documentation that is version inconsistent (I think... label vs div around outlined notched text e.g.) .. I have issues with helper text not being displayed anymore too but can't get to latest state to verify whether it is me or it has been fixed. Looking forward to a build that can "build" - or at least updated getting started with the new style changes you have made...

[asyncLiz]

If you're using some of the latest canary snapshots, make sure you're using the latest version of sass for the module system.

[cintaccs]

Thanks for the feedback! I am using "sass-loader": "^8.0.2", with webpack. And have something "node-sass": "^4.13.1",like this in my devDependencies too. Usually I check whether anything is outdated - and I should be all up to date... is that the version you refer to?

[asyncLiz]

You'll want to switch to sass instead of node-sass, which is based off dart-sass and is updated for the module system. According to sass-loader's implementation section it should automatically use sass once you uninstall node-sass and install the different implementation.

[cintaccs]

That was it!! thanks a million! I had to remove @import "@material/grid-list/mdc-grid-list"; and change the order of sass dependencies and updated my webpack configs - but then I can compile the latest and greatest - and everything looks good apart from some custom implementation of trailing icons in a notched outlined text field in dense-compact. 🥇 to you and thanks for taking time to help! Now I can better watch over loose events :-) --- who would have thought that being on the latest canary build feels so good :-)

[zandaqo]

This thing causes a rather nasty memory leak in my app. I'm using material web components with LitElement and every time I render a component using ripple, it attaches an event listener to the resize event of the window. It fails to detach the listener upon being removed from the DOM, hence, the element sticks around and keeps the whole tree above as detached elements in memory causing a leak. Only manually removing those listeners allows the GC to clean up detached elements.