+++ This bug was initially created as a clone of Bug #271405 +++ - It's quite amazing how often we're running checkPublicRecipientsLimit() without doing anything, which might affect performance with many recipients (think mass mails, the very use case of this feature!) and when using recipient autocomplete. - Also our Fluent isn't quite fluent yet (see next comment). https://searchfox.org/comm-central/rev/e5e75651c5fb70526ae298312d99bc37ffd1ad32/mail/components/compose/content/MsgComposeCommands.js#3731-3739 ``` // Observe the changes of message recipient rows. gRecipientObserver = new MutationObserver(function(mutations) { if (mutations.some(m => m.type == "childList")) { checkPublicRecipientsLimit(); } }); gRecipientObserver.observe(document.getElementById("toAddrContainer"), { childList: true, }); ``` We're constructing the observer correctly, but then observing only the `To` field... Yet the notification also works for `Cc`, so there must be something else... here: https://searchfox.org/comm-central/rev/e5e75651c5fb70526ae298312d99bc37ffd1ad32/mail/components/compose/content/MsgComposeCommands.js#5589-5597 ``` function onRecipientsChanged(automatic) { if (!automatic) { gContentChanged = true; } if (gRecipientObserver) { checkPublicRecipientsLimit(); } updateSendCommands(true); } ``` Right, here's where we start going into overdrive: - `onRecipientsChanged()` gets called [here](https://searchfox.org/comm-central/rev/e5e75651c5fb70526ae298312d99bc37ffd1ad32/mail/components/compose/content/addressingWidgetOverlay.js#904-907) for every input event of every autocomplete address input (including Bcc!), which in turn calls `checkPublicRecipientsLimit()`. Here's the net result: - When you type `john.doe@example.com`, it will call `checkPublicRecipientsLimit()` for each character entered: that's 20 calls. - If your topmost autocomplete result changes with each character, that may add up to 20 calls again. - So you may have **40 calls for a single address**, however, as long as that address is still plain text (not pillified), we won't even count it for the notification... So that's a lot of no-op! Plus, every pill which you add or remove manually in the `To` field will needlessly be double-checked: once by the direct `gRecipientObserver`, and then again by `onRecipientsChanged()`. - So adding 20 pills manually in `To` field will do 40 checks (in addition to the check-as-you-type calls) - more no-op! - Btw, reply-all triggers the observer for each and every reply address, whereas pressing `Enter` after comma-separated addresses gets counted by the observer as a single childList change - should look into that difference, too! So the **total no-op calls to `checkPublicRecipientsLimit` when entering 20 `To` recipients manually** may be like this: 20 recipients x 20 chars x2 for character autocompletion + 20 for final autocompletion + 20 from observer for adding pill. That's a whopping **120 calls where 20 should suffice if we're only counting pills.** Btw dragging an address from one field to another field which has pills already creates as many as 6 `onRecipientsChanged()` calls...
Bug 1717085 Comment 0 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
+++ This bug was initially created as a clone of Bug #271405 +++ - It's quite amazing how often we're running checkPublicRecipientsLimit() without doing anything, which might affect performance with many recipients (think mass mails, the very use case of this feature!) and when using recipient autocomplete. - Also our Fluent isn't quite fluent yet (see next comment). https://searchfox.org/comm-central/rev/e5e75651c5fb70526ae298312d99bc37ffd1ad32/mail/components/compose/content/MsgComposeCommands.js#3731-3739 ``` // Observe the changes of message recipient rows. gRecipientObserver = new MutationObserver(function(mutations) { if (mutations.some(m => m.type == "childList")) { checkPublicRecipientsLimit(); } }); gRecipientObserver.observe(document.getElementById("toAddrContainer"), { childList: true, }); ``` We're constructing the observer correctly, but then observing only the `To` field... Yet the notification also works for `Cc`, so there must be something else... here: https://searchfox.org/comm-central/rev/e5e75651c5fb70526ae298312d99bc37ffd1ad32/mail/components/compose/content/MsgComposeCommands.js#5589-5597 ``` function onRecipientsChanged(automatic) { if (!automatic) { gContentChanged = true; } if (gRecipientObserver) { checkPublicRecipientsLimit(); } updateSendCommands(true); } ``` Right, here's where we start going into overdrive: - `onRecipientsChanged()` gets called [here](https://searchfox.org/comm-central/rev/e5e75651c5fb70526ae298312d99bc37ffd1ad32/mail/components/compose/content/addressingWidgetOverlay.js#904-907) for every input event of every autocomplete address input (including Bcc!), which in turn calls `checkPublicRecipientsLimit()`. Here's the net result: - When you type `john.doe@example.com`, it will call `checkPublicRecipientsLimit()` for each character entered: that's 20 calls. - If your topmost autocomplete result changes with each character, that may add up to 20 calls again. - So you may have **40 calls for a single address**, however, as long as that address is still plain text (not pillified), we won't even count it for the notification... So that's a lot of no-op! Plus, every pill which you add or remove manually in the `To` field will needlessly be double-checked: once by the direct `gRecipientObserver`, and then again by `onRecipientsChanged()`. - So adding 20 pills manually in `To` field will do 40 checks (in addition to the check-as-you-type calls) - more no-op! - Btw, reply-all triggers the observer for each and every reply address, whereas pressing `Enter` after comma-separated addresses gets counted by the observer as a single childList change - should look into that difference, too! So the **total no-op calls of `checkPublicRecipientsLimit` when entering 20 `To` recipients manually** may be like this: 20 recipients x 20 chars x2 for character autocompletion + 20 for final autocompletion + 20 from observer for adding pill. That's a whopping **120 calls where 20 should suffice if we're only counting pills.** Btw dragging an address from one field to another field which has pills already creates as many as 6 `onRecipientsChanged()` calls...
+++ This bug was initially created as a clone of Bug #271405 +++ - It's quite amazing how often we're running checkPublicRecipientsLimit() without doing anything, which might affect performance with many recipients (think mass mails, the very use case of this feature!) and when using recipient autocomplete. Something wrong with the way we listen for changes here. - Also our Fluent isn't quite fluent yet (see next comment). https://searchfox.org/comm-central/rev/e5e75651c5fb70526ae298312d99bc37ffd1ad32/mail/components/compose/content/MsgComposeCommands.js#3731-3739 ``` // Observe the changes of message recipient rows. gRecipientObserver = new MutationObserver(function(mutations) { if (mutations.some(m => m.type == "childList")) { checkPublicRecipientsLimit(); } }); gRecipientObserver.observe(document.getElementById("toAddrContainer"), { childList: true, }); ``` We're constructing the observer correctly, but then observing only the `To` field... Yet the notification also works for `Cc`, so there must be something else... here: https://searchfox.org/comm-central/rev/e5e75651c5fb70526ae298312d99bc37ffd1ad32/mail/components/compose/content/MsgComposeCommands.js#5589-5597 ``` function onRecipientsChanged(automatic) { if (!automatic) { gContentChanged = true; } if (gRecipientObserver) { checkPublicRecipientsLimit(); } updateSendCommands(true); } ``` Right, here's where we start going into overdrive: - `onRecipientsChanged()` gets called [here](https://searchfox.org/comm-central/rev/e5e75651c5fb70526ae298312d99bc37ffd1ad32/mail/components/compose/content/addressingWidgetOverlay.js#904-907) for every input event of every autocomplete address input (including Bcc!), which in turn calls `checkPublicRecipientsLimit()`. Here's the net result: - When you type `john.doe@example.com`, it will call `checkPublicRecipientsLimit()` for each character entered: that's 20 calls. - If your topmost autocomplete result changes with each character, that may add up to 20 calls again. - So you may have **40 calls for a single address**, however, as long as that address is still plain text (not pillified), we won't even count it for the notification... So that's a lot of no-op! Plus, every pill which you add or remove manually in the `To` field will needlessly be double-checked: once by the direct `gRecipientObserver`, and then again by `onRecipientsChanged()`. - So adding 20 pills manually in `To` field will do 40 checks (in addition to the check-as-you-type calls) - more no-op! - Btw, reply-all triggers the observer for each and every reply address, whereas pressing `Enter` after comma-separated addresses gets counted by the observer as a single childList change - should look into that difference, too! So the **total no-op calls of `checkPublicRecipientsLimit` when entering 20 `To` recipients manually** may be like this: 20 recipients x 20 chars x2 for character autocompletion + 20 for final autocompletion + 20 from observer for adding pill. That's a whopping **120 calls where 20 should suffice if we're only counting pills.** Btw dragging an address from one field to another field which has pills already creates as many as 6 `onRecipientsChanged()` calls...
+++ This bug was initially created as a clone of Bug #271405 +++ - It's quite amazing how often we're running checkPublicRecipientsLimit() without doing anything, which might affect performance with many recipients (think mass mails, the very use case of this feature!) and when using recipient autocomplete. Something wrong with the way we listen for changes here. - Also our Fluent isn't quite fluent yet (see next comment). https://searchfox.org/comm-central/rev/e5e75651c5fb70526ae298312d99bc37ffd1ad32/mail/components/compose/content/MsgComposeCommands.js#3731-3739 ``` // Observe the changes of message recipient rows. gRecipientObserver = new MutationObserver(function(mutations) { if (mutations.some(m => m.type == "childList")) { checkPublicRecipientsLimit(); } }); gRecipientObserver.observe(document.getElementById("toAddrContainer"), { childList: true, }); ``` We're constructing the observer correctly, but then observing only the `To` field... Yet the notification also works for `Cc`, so there must be something else... here: https://searchfox.org/comm-central/rev/e5e75651c5fb70526ae298312d99bc37ffd1ad32/mail/components/compose/content/MsgComposeCommands.js#5589-5597 ``` function onRecipientsChanged(automatic) { if (!automatic) { gContentChanged = true; } if (gRecipientObserver) { checkPublicRecipientsLimit(); } updateSendCommands(true); } ``` Right, here's where we start going into overdrive: - `onRecipientsChanged()` gets called [here](https://searchfox.org/comm-central/rev/e5e75651c5fb70526ae298312d99bc37ffd1ad32/mail/components/compose/content/addressingWidgetOverlay.js#904-907) for every input event of every autocomplete address input (including Bcc!), which in turn calls `checkPublicRecipientsLimit()`. Here's the net result: - When you type `john.doe@example.com`, it will call `checkPublicRecipientsLimit()` for each character entered: that's 20 calls. - If your topmost autocomplete result changes with each character, that may add up to 20 calls again. - So you may have **40 calls for a single address**, however, as long as that address is still plain text (not pillified), we won't even count it for the notification... So that's a lot of no-op! Plus, every pill which you add or remove manually in the `To` field will needlessly be double-checked: once by the direct `gRecipientObserver`, and then again by `onRecipientsChanged()`. - So adding 20 pills manually in `To` field will do 40 checks (in addition to the check-as-you-type calls) - more no-op! - Btw, reply-all triggers the observer for each and every reply address, whereas pressing `Enter` after comma-separated addresses gets counted by the observer as a single childList change - should look into that difference, too! So the **total no-op calls of `checkPublicRecipientsLimit` when entering 20 `To` recipients manually** may be like this: 20 recipients x 20 chars x2 for character autocompletion + 20 for final autocompletion + 20 from observer for adding pill. That's a whopping **840 calls where 20 should suffice if we're only counting pills.** Btw dragging an address from one field to another field which has pills already creates as many as 6 `onRecipientsChanged()` calls...
+++ This bug was initially created as a clone of Bug #271405 +++ - It's quite amazing how often we're running checkPublicRecipientsLimit() without doing anything, which might affect performance with many recipients (think mass mails, the very use case of this feature!) and when using recipient autocomplete. Something wrong with the way we listen for changes here. - Also our Fluent isn't quite fluent yet (see next comment). https://searchfox.org/comm-central/rev/e5e75651c5fb70526ae298312d99bc37ffd1ad32/mail/components/compose/content/MsgComposeCommands.js#3731-3739 ``` // Observe the changes of message recipient rows. gRecipientObserver = new MutationObserver(function(mutations) { if (mutations.some(m => m.type == "childList")) { checkPublicRecipientsLimit(); } }); gRecipientObserver.observe(document.getElementById("toAddrContainer"), { childList: true, }); ``` We're constructing the observer correctly, but then observing only the `To` field... Yet the notification also works for `Cc`, so there must be something else... here: https://searchfox.org/comm-central/rev/e5e75651c5fb70526ae298312d99bc37ffd1ad32/mail/components/compose/content/MsgComposeCommands.js#5589-5597 ``` function onRecipientsChanged(automatic) { if (!automatic) { gContentChanged = true; } if (gRecipientObserver) { checkPublicRecipientsLimit(); } updateSendCommands(true); } ``` Right, here's where we start going into overdrive: - `onRecipientsChanged()` gets called [here](https://searchfox.org/comm-central/rev/e5e75651c5fb70526ae298312d99bc37ffd1ad32/mail/components/compose/content/addressingWidgetOverlay.js#904-907) for every input event of every autocomplete address input (including Bcc!), which in turn calls `checkPublicRecipientsLimit()`. Here's the net result: - When you type `john.doe@example.com`, it will call `checkPublicRecipientsLimit()` for each character entered: that's 20 calls. - If your topmost autocomplete result changes with each character, that may add up to 20 calls again. - So you may have **40 calls for a single address**, however, as long as that address is still plain text (not pillified), we won't even count it for the notification... So that's a lot of no-op! Plus, every pill which you add or remove manually in the `To` field will needlessly be double-checked: once by the direct `gRecipientObserver`, and then again by `onRecipientsChanged()`. - So adding 20 pills manually in `To` field will do 40 checks (in addition to the check-as-you-type calls) - more no-op! - Btw, reply-all triggers the observer for each and every reply address, whereas pressing `Enter` after comma-separated addresses gets counted by the observer as a single childList change - should look into that difference, too! So the **total no-op calls of `checkPublicRecipientsLimit` when entering 20 `To` recipients manually** may be like this: 20 recipients x 20 chars x2 for character autocompletion + 20 for final autocompletion + 20 from observer for adding pill. That's a whopping **840 calls where 20 should suffice if we're only counting pills.** Btw dragging an address from one field to another field which has pills already creates as many as 6 `onRecipientsChanged()` calls...
+++ This bug was initially created as a clone of Bug #271405 +++ - It's quite amazing how often we're running checkPublicRecipientsLimit() without doing anything, which might affect performance with many recipients (think mass mails, the very use case of this feature!) and when using recipient autocomplete. Something wrong with the way we listen for changes here. - Also our Fluent isn't quite fluent yet (see next comment). https://searchfox.org/comm-central/rev/e5e75651c5fb70526ae298312d99bc37ffd1ad32/mail/components/compose/content/MsgComposeCommands.js#3731-3739 ``` // Observe the changes of message recipient rows. gRecipientObserver = new MutationObserver(function(mutations) { if (mutations.some(m => m.type == "childList")) { checkPublicRecipientsLimit(); } }); gRecipientObserver.observe(document.getElementById("toAddrContainer"), { childList: true, }); ``` We're constructing the observer correctly, but then observing only the `To` field... Yet the notification also works for `Cc`, so there must be something else... here: https://searchfox.org/comm-central/rev/e5e75651c5fb70526ae298312d99bc37ffd1ad32/mail/components/compose/content/MsgComposeCommands.js#5589-5597 ``` function onRecipientsChanged(automatic) { if (!automatic) { gContentChanged = true; } if (gRecipientObserver) { checkPublicRecipientsLimit(); } updateSendCommands(true); } ``` Right, here's where we start going into overdrive: - `onRecipientsChanged()` gets called [here](https://searchfox.org/comm-central/rev/e5e75651c5fb70526ae298312d99bc37ffd1ad32/mail/components/compose/content/addressingWidgetOverlay.js#904-907) for every input event of every autocomplete address input field (including Bcc!), which in turn calls `checkPublicRecipientsLimit()`. Here's the net result: - When you type `john.doe@example.com`, it will call `checkPublicRecipientsLimit()` for each character entered: that's 20 calls. - If your topmost autocomplete result changes with each character, that may add up to 20 calls again. - So you may have **40 calls for a single address**, however, as long as that address is still plain text (not pillified), we won't even count it for the notification... So that's a lot of no-op! Plus, every pill which you add or remove manually in the `To` field will needlessly be double-checked: once by the direct `gRecipientObserver`, and then again by `onRecipientsChanged()`. - So adding 20 pills manually in `To` field will do 40 checks (in addition to the check-as-you-type calls) - more no-op! - Btw, reply-all triggers the observer for each and every reply address, whereas pressing `Enter` after comma-separated addresses gets counted by the observer as a single childList change - should look into that difference, too! So the **total no-op calls of `checkPublicRecipientsLimit` when entering 20 `To` recipients manually** may be like this: 20 recipients x 20 chars x2 for character autocompletion + 20 for final autocompletion + 20 from observer for adding pill. That's a whopping **840 calls where 20 should suffice if we're only counting pills.** Btw dragging an address from one field to another field which has pills already creates as many as 6 `onRecipientsChanged()` calls...
+++ This bug was initially created as a clone of Bug #271405 +++ - It's quite amazing how often we're running checkPublicRecipientsLimit() without doing anything, which might affect performance with many recipients (think mass mails, the very use case of this feature!) and when using recipient autocomplete. Something wrong with the way we listen for changes here. - Also our Fluent isn't quite fluent yet (see next comment). https://searchfox.org/comm-central/rev/e5e75651c5fb70526ae298312d99bc37ffd1ad32/mail/components/compose/content/MsgComposeCommands.js#3731-3739 ``` // Observe the changes of message recipient rows. gRecipientObserver = new MutationObserver(function(mutations) { if (mutations.some(m => m.type == "childList")) { checkPublicRecipientsLimit(); } }); gRecipientObserver.observe(document.getElementById("toAddrContainer"), { childList: true, }); ``` We're constructing the observer correctly, but then observing only the `To` field... Yet the notification also works for `Cc`, so there must be something else... here: https://searchfox.org/comm-central/rev/e5e75651c5fb70526ae298312d99bc37ffd1ad32/mail/components/compose/content/MsgComposeCommands.js#5589-5597 ``` function onRecipientsChanged(automatic) { if (!automatic) { gContentChanged = true; } if (gRecipientObserver) { checkPublicRecipientsLimit(); } updateSendCommands(true); } ``` Right, here's where we start going into overdrive: - `onRecipientsChanged()` gets called [here](https://searchfox.org/comm-central/rev/e5e75651c5fb70526ae298312d99bc37ffd1ad32/mail/components/compose/content/addressingWidgetOverlay.js#904-907) for every input event of every autocomplete address input field (including Bcc!), which in turn calls `checkPublicRecipientsLimit()`. Here's the net result: - When you type `john.doe@example.com`, it will call `checkPublicRecipientsLimit()` for each character entered: that's 20 calls. - If your topmost autocomplete result changes with each character, that may add up to 20 calls again. - So you may have **40 calls for a single address**, however, as long as that address is still plain text (not pillified), we won't even count it for the notification... So that's a lot of no-op! Plus, every pill which you add or remove manually in the `To` field will needlessly be double-checked: once by the direct `gRecipientObserver`, and then again by `onRecipientsChanged()`. - So adding 20 pills manually in `To` field will do 40 checks (in addition to the check-as-you-type calls) - more no-op! - Btw, reply-all triggers the observer for each and every reply address, whereas pressing `Enter` after comma-separated addresses gets counted by the observer as a single childList change - should look into that difference, too! (in another bug) So the **total no-op calls of `checkPublicRecipientsLimit` when entering 20 `To` recipients manually** may be like this: 20 recipients x 20 chars x2 for character autocompletion + 20 for final autocompletion + 20 from observer for adding pill. That's a whopping **840 calls where 20 should suffice if we're only counting pills.** Btw dragging an address from one field to another field which has pills already creates as many as 6 `onRecipientsChanged()` calls...
+++ This bug was initially created as a clone of Bug #271405 +++ - It's quite amazing how often we're running checkPublicRecipientsLimit() without doing anything, which might affect performance with many recipients (think mass mails, the very use case of this feature!) and when using recipient autocomplete. Something wrong with the way we listen for changes here. - Also our Fluent isn't quite fluent yet (see comment 3). https://searchfox.org/comm-central/rev/e5e75651c5fb70526ae298312d99bc37ffd1ad32/mail/components/compose/content/MsgComposeCommands.js#3731-3739 ``` // Observe the changes of message recipient rows. gRecipientObserver = new MutationObserver(function(mutations) { if (mutations.some(m => m.type == "childList")) { checkPublicRecipientsLimit(); } }); gRecipientObserver.observe(document.getElementById("toAddrContainer"), { childList: true, }); ``` We're constructing the observer correctly, but then observing only the `To` field... Yet the notification also works for `Cc`, so there must be something else... here: https://searchfox.org/comm-central/rev/e5e75651c5fb70526ae298312d99bc37ffd1ad32/mail/components/compose/content/MsgComposeCommands.js#5589-5597 ``` function onRecipientsChanged(automatic) { if (!automatic) { gContentChanged = true; } if (gRecipientObserver) { checkPublicRecipientsLimit(); } updateSendCommands(true); } ``` Right, here's where we start going into overdrive: - `onRecipientsChanged()` gets called [here](https://searchfox.org/comm-central/rev/e5e75651c5fb70526ae298312d99bc37ffd1ad32/mail/components/compose/content/addressingWidgetOverlay.js#904-907) for every input event of every autocomplete address input field (including Bcc!), which in turn calls `checkPublicRecipientsLimit()`. Here's the net result: - When you type `john.doe@example.com`, it will call `checkPublicRecipientsLimit()` for each character entered: that's 20 calls. - If your topmost autocomplete result changes with each character, that may add up to 20 calls again. - So you may have **40 calls for a single address**, however, as long as that address is still plain text (not pillified), we won't even count it for the notification... So that's a lot of no-op! Plus, every pill which you add or remove manually in the `To` field will needlessly be double-checked: once by the direct `gRecipientObserver`, and then again by `onRecipientsChanged()`. - So adding 20 pills manually in `To` field will do 40 checks (in addition to the check-as-you-type calls) - more no-op! - Btw, reply-all triggers the observer for each and every reply address, whereas pressing `Enter` after comma-separated addresses gets counted by the observer as a single childList change - should look into that difference, too! (in another bug) So the **total no-op calls of `checkPublicRecipientsLimit` when entering 20 `To` recipients manually** may be like this: 20 recipients x 20 chars x2 for character autocompletion + 20 for final autocompletion + 20 from observer for adding pill. That's a whopping **840 calls where 20 should suffice if we're only counting pills.** Btw dragging an address from one field to another field which has pills already creates as many as 6 `onRecipientsChanged()` calls...
+++ This bug was initially created as a clone of Bug #271405 +++ - It's quite amazing how often we're running `checkPublicRecipientsLimit()` without doing anything, which might affect performance with many recipients (think mass mails, the very use case of this feature!) and when using recipient autocomplete. Something wrong with the way we listen for changes here. - Also our Fluent isn't quite fluent yet (see comment 3). https://searchfox.org/comm-central/rev/e5e75651c5fb70526ae298312d99bc37ffd1ad32/mail/components/compose/content/MsgComposeCommands.js#3731-3739 ``` // Observe the changes of message recipient rows. gRecipientObserver = new MutationObserver(function(mutations) { if (mutations.some(m => m.type == "childList")) { checkPublicRecipientsLimit(); } }); gRecipientObserver.observe(document.getElementById("toAddrContainer"), { childList: true, }); ``` We're constructing the observer correctly, but then observing only the `To` field... Yet the notification also works for `Cc`, so there must be something else... here: https://searchfox.org/comm-central/rev/e5e75651c5fb70526ae298312d99bc37ffd1ad32/mail/components/compose/content/MsgComposeCommands.js#5589-5597 ``` function onRecipientsChanged(automatic) { if (!automatic) { gContentChanged = true; } if (gRecipientObserver) { checkPublicRecipientsLimit(); } updateSendCommands(true); } ``` Right, here's where we start going into overdrive: - `onRecipientsChanged()` gets called [here](https://searchfox.org/comm-central/rev/e5e75651c5fb70526ae298312d99bc37ffd1ad32/mail/components/compose/content/addressingWidgetOverlay.js#904-907) for every input event of every autocomplete address input field (including Bcc!), which in turn calls `checkPublicRecipientsLimit()`. Here's the net result: - When you type `john.doe@example.com`, it will call `checkPublicRecipientsLimit()` for each character entered: that's 20 calls. - If your topmost autocomplete result changes with each character, that may add up to 20 calls again. - So you may have **40 calls for a single address**, however, as long as that address is still plain text (not pillified), we won't even count it for the notification... So that's a lot of no-op! Plus, every pill which you add or remove manually in the `To` field will needlessly be double-checked: once by the direct `gRecipientObserver`, and then again by `onRecipientsChanged()`. - So adding 20 pills manually in `To` field will do 40 checks (in addition to the check-as-you-type calls) - more no-op! - Btw, reply-all triggers the observer for each and every reply address, whereas pressing `Enter` after comma-separated addresses gets counted by the observer as a single childList change - should look into that difference, too! (in another bug) So the **total no-op calls of `checkPublicRecipientsLimit` when entering 20 `To` recipients manually** may be like this: 20 recipients x 20 chars x2 for character autocompletion + 20 for final autocompletion + 20 from observer for adding pill. That's a whopping **840 calls where 20 should suffice if we're only counting pills.** Btw dragging an address from one field to another field which has pills already creates as many as 6 `onRecipientsChanged()` calls...
+++ This bug was initially created as a clone of Bug #271405 +++ - It's quite amazing how often we're running `checkPublicRecipientsLimit()` without doing anything, which might affect performance with many recipients (think mass mails, the very use case of this feature!) and when using recipient autocomplete. Something wrong with the way we listen for changes here. - Also our Fluent isn't quite fluent yet (see comment 3). https://searchfox.org/comm-central/rev/e5e75651c5fb70526ae298312d99bc37ffd1ad32/mail/components/compose/content/MsgComposeCommands.js#3731-3739 ``` // Observe the changes of message recipient rows. gRecipientObserver = new MutationObserver(function(mutations) { if (mutations.some(m => m.type == "childList")) { checkPublicRecipientsLimit(); } }); gRecipientObserver.observe(document.getElementById("toAddrContainer"), { childList: true, }); ``` We're constructing the observer correctly, but then observing only the `To` field... Yet the notification also works for `Cc`, so there must be something else... here: https://searchfox.org/comm-central/rev/e5e75651c5fb70526ae298312d99bc37ffd1ad32/mail/components/compose/content/MsgComposeCommands.js#5589-5597 ``` function onRecipientsChanged(automatic) { if (!automatic) { gContentChanged = true; } if (gRecipientObserver) { checkPublicRecipientsLimit(); } updateSendCommands(true); } ``` Right, here's where we start going into overdrive: - `onRecipientsChanged()` gets called [here](https://searchfox.org/comm-central/rev/e5e75651c5fb70526ae298312d99bc37ffd1ad32/mail/components/compose/content/addressingWidgetOverlay.js#904-907) for every input event of every autocomplete address input field (including `Bcc`!), which in turn calls `checkPublicRecipientsLimit()`. Here's the net result: - When you type `john.doe@example.com`, it will call `checkPublicRecipientsLimit()` for each character entered: that's 20 calls. - If your topmost autocomplete result changes with each character, that may add up to 20 calls again. - So you may have **40 calls for a single address**, however, as long as that address is still plain text (not pillified), we won't even count it for the notification... So that's a lot of no-op! Plus, every pill which you add or remove manually in the `To` field will needlessly be double-checked: once by the direct `gRecipientObserver`, and then again by `onRecipientsChanged()`. - So adding 20 pills manually in `To` field will do 40 checks (in addition to the check-as-you-type calls) - more no-op! - Btw, reply-all triggers the observer for each and every reply address, whereas pressing `Enter` after comma-separated addresses gets counted by the observer as a single childList change - should look into that difference, too! (in another bug) So the **total no-op calls of `checkPublicRecipientsLimit` when entering 20 `To` recipients manually** may be like this: 20 recipients x 20 chars x2 for character autocompletion + 20 for final autocompletion + 20 from observer for adding pill. That's a whopping **840 calls where 20 should suffice if we're only counting pills.** Btw dragging an address from one field to another field which has pills already creates as many as 6 `onRecipientsChanged()` calls...