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

[ionh]

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?

[josteink]

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?

[bchenhs]

We ran into this earlier and found a workaround. There are two parts to the fix:

1. Insert the setTimeout to yield and let Gmail view to render. We placed it here where insertion_observer is invoked.
2. Update the insertion_observer implementation to handle all message elements within a thread correctly:

if (element.length) {
  var handler = config.handler ? config.handler : function(match, callback) { callback(match); };
  let idx;
  for (idx = 0; idx < element.length; idx++) {
    // console.log( "inserted DOM: class match in watchdog",observer,api.tracker.watchdog.dom[observer] );
    api.observe.trigger_dom(observer, $(element[idx]), handler);
  }
}

Notes:

• We haven't fully tested this, especially on a Gmail account on an old behaviour.

[josteink]

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

PRs are definitely welcome.

[bchenhs]

@josteink I don't seem to have permission to push a branch here. Are there steps to follow to contribute?

[josteink]

For now just fork and create a regular "external" PR from your own repo.

I can review, merge and push here.

[bchenhs]

Here it is:
bchenhs/gmail.js-fork#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.

[josteink]

I appreciate the effort, but it seems to me you didn't create a "linked" fork by clicking the fork button in the upper right region of this repo.

When you do that you can create pull requests (patches for review) straight back to this repo without any special access.

GitHub has docs on this, and I'm sure there are lots of guides on YouTube too.

Check this out, and see if you can make the PR show up in this repo? 🙂

https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-a-pull-request-from-a-fork

[onestep]

@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.

[josteink]

@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.

That's great news!

I'm kinda busy at a conference now though.

If someone could prep a PR which contains the following:

• actual fix
• updated version in package.json
• updated change-log

If someone does that, I'll try to get it merged and pushed to npmjs as soon as I can, possibly later today.

Do you think you can do that, @onestep ?

[josteink]

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

Let me know if it works for you 😄

[ionh]

Hello guys. It works now, the event is fired, but it is fired 4 times and sometimes 3 times when you open an email.

[josteink]

@ionh : Can you test this with the latest PR from @cancan101 ?

#767

[ionh]

Sorry guys for the long response, just managed to pull the latest version which includes #767, unfortunately, the event continues to be fired 3 times in a row. For me is not a problem, my script just adds a button on the page after the email is opened, so I did a workaround, if the button is already added do not run the script on every triggered event.

[josteink]

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 😃

[Duc-Developer]

Hi @josteink , this problem is very important to me, I have used the latest version (v1.1.12) but this problem still occurs. Do you have any pr for quick modifications to it? I can refer to the modification section to quickly apply it to my project. Thanks!

[josteink]

My suggestion above was above making changes to your own extension to make sure you, in your code, handle the event in a way where (depending on your needs), the crucial code on your part is only triggered once.

There's currently no PR or fix for this. If someone wants to fix this and provide a PR, I will be happy to merge it and provide a new release.