gmail.js: gmail.observe.on('view_email', () => {}) is not fired

have this code from the boilerplate but looks like now view_email is not fired anymore? Other events like view_thread or compose are working

gmail.observe.on("load", () => {
    const userEmail = gmail.get.user_email();
    console.log("Hello, " + userEmail + ". This is your extension talking!");

    gmail.observe.on("view_email", (domEmail) => {
        console.log("Looking at email:", domEmail);
        const emailData = gmail.new.get.email_data(domEmail);
        console.log("Email data:", emailData);
    });

    gmail.observe.on("compose", (compose) => {
        console.log("New compose window is opened!", compose);
    });
});

Any ideas?

About this issue

Original URL
State: open
Created 9 months ago
Comments: 16 (1 by maintainers)

Commits related to this issue

Update insertion_observer for new Gmail updates Based on https://github.com/bchenhs/gmail.js-fork/commit/36054749347adf382e8d1c670a8b2dd6a0e9d79a To fix https://github.com/KartikTalwar/gmail.js/is... — committed to compose-ai/gmail.js by mitchellw 9 months ago

Most upvoted comments

Ok guys. 1.1.11, the most 1ish version ever released was just pushed to npmjs.

Let me know if it works for you 😄

josteink on Sep 20, 2023

I’ve always been doing that anyway (making the event-handler idempotent), since thread rendering in Gmail does not seem to be entirely deterministic.

It’s probably for the best 😃

josteink on Jan 5, 2024

@josteink I’ve tried your draft fix from this comment and it works fine for both private and GSuite accounts.

I think it could be more safe to fix particulalry this handler instead of changing insertion_observer implementation, as some applications may rely on immediate reaction to DOM changes.

onestep on Sep 20, 2023

Here it is: https://github.com/bchenhs/gmail.js-fork/pull/1

Notes:

There is one outstanding issue, where only get the first 5 unread messages in a thread gets registered. We don’t have a solution on this yet.

bchenhs on Sep 19, 2023

Seems like you are a week ahead of me then, in terms of debugging, fixing and testing.

PRs are definitely welcome.

josteink on Sep 18, 2023

Hey there and thanks for the bug-report.

I’ve tested and I can reproduce. I’ve given this a little run in the debugger and it seems to be timing-related.

That is, our selectors are correct, but we are trying to look for a HTML element which has not yet been inserted when our code runs.

There may be different (and better) ways to fix this, but I managed to get the event triggering by making this small change:

                 // class depends if is_preview_pane - Bu for preview pane, nH for standard view,
                 // FIXME: the empty class ("") is for emails opened after thread is rendered (causes a storm of updates)
                 class: ["Bu", "nH", ""],
-                sub_selector: "div.adn",
                 handler: function(match, callback) {
-                    match = new api.dom.email(match);
-                    callback(match);
+                    setTimeout(() => {
+                        match = match.find("div.adn.ads");
+                        if (match.length) {
+                            match = new api.dom.email(match);
+                            callback(match);
+                        }
+                    }, 0);
                 }
             },

This probably should be looked into a bit deeper, and a new version will need to be released.

Do you have the ability to help out testing the above patch on your end?

josteink on Sep 18, 2023