Open mohammedfarhan99 opened 1 month ago
Hey there and thanks for the very detailed issue report.
I agree this sounds like something which should be handled within Gmail.js itself.
My best suggestion would be to inspect the code for the gmail.tools.add_toolbar_button()
function and see what sort of CSS selectors it uses. Maybe they can be adjusted so that we avoid the issue entirely? In that case, you might just submit a PR with those changes.
If you think something more complicated will be required, lets keep this issue open, so we can discuss possible solutions here, with a full context and code sample which is easy to refer to, and for others to join in on.
Let me know what you find 😄
Thanks for the prompt response @josteink !
I don't think the css selector is an issue here. Here's how the add toolbar picks the parent element:
api.dom.toolbar = function() {
var tb = $("[gh='mtb']");
while($(tb).children().length === 1){
tb = $(tb).children().first();
}
return tb;
};
And all gmail.tools.add_toolbar_button()
does is add a child to it:
https://github.com/KartikTalwar/gmail.js/blob/7430d03b7c76551ac02978a811f3f7f38793db13/src/gmail.js#L3686
But the issue is that the child's style is mutated, possibly by some useEffect-esque function in gmail's js
Have you encountered similar issues in the past? What's the best way to solve this?
Here's a slightly different, but more reliable change:
// Get the DOM element from the jQuery object
const parentElHTML = parentEl.get(0);
const observer = new MutationObserver(mutationsList => {
for (let mutation of mutationsList) {
if (
mutation.type === 'attributes' &&
mutation.attributeName === 'style'
) {
if (mutation.target && mutation.target.style && mutation.target.style.display === 'none') {
// Detected change, forcing display to block
mutation.target.style.display = 'block'; // Force visibility
}
}
}
});
// Observe for changes in the target element's style attribute
observer.observe(parentElHTML, {
attributes: true,
attributeFilter: ['style'],
});
To be honest, the only thing I have in my extension is a function which idempotently adds the toolbar buttons on every navigation event (ie it checks if the bar is there, and if not, it adds it).
That's all I do, and that seems to work for me.
Context
In our chrome extension, we inject a button into gmail's toolbar,via gmailjs'
add_toolbar_button
button api, via this func (code modified for brevity):Incident Report
After the newest chrome update to version
129.0.6668.70
, this injected button appears into gmail's toolbar for a couple of seconds and disappears, so to alleviate that we tried adding a setTimeout to where we call this function, which is in the event handlers ofhashChange
andload
So previously in these event handlers if we calledaddButton()
directly now it would change tosetTimeout(addButton, 5000)
,Although this would make our injected button appear after 4s, it would still disappear once again. But at least now we would notice that our injected button appears on gmail's toolbar dom, but not on gmail's toolbar itself, the reason for this being that the parent element of our injected button has a css style of
{ display: none }
which was causing our button to not appear in the toolbarSo we modify our above function to also see if the parent's css has display as
none
and if it does, then we modify the property of display to 'block'.So the function is rewritten to accommodate the button's parent css
Conclusion
This rewrite works, but it feels like this solution is a little hacky and seems like something that's best handled within gmail-js itself. If anyone could pick it up, that would be great. Otherwise, would love some guidance as to the best place to handle this, and a good practice to handle it, since I'm sure gmail-js would have had to handle similar issues in the past