new.get.thread_id does not return thread id after google workspace change

[sieppl]

For unkown reasons in Google Workspace the legacy thread id is set, but the new one not:

I suggest adding a fallback like this to the function:

api.new.get.thread_id = function() {
    const threadElem = document.querySelector("[data-thread-perm-id]");
    if (!threadElem) {
        return null;
    }
    
    const threadPermId = threadElem.dataset["threadPermId"];
    
    // Fall back to legacy thread ID if perm ID is undefined or the string "undefined"
    if (!threadPermId || threadPermId === "undefined") {
        return threadElem.dataset["legacyThreadId"] || null;
    }
    
    return threadPermId;
};

[josteink]

Thanks for reporting. This looks weird, but as long as we have one of the IDs we should be able to make things work.

I’m not sure what I think about adding a fallback into that function, without investigating the consequences first.

I’ll try to look into this the next few days.

[josteink]

After testing, I've been able to reproduce this issue myself in a few threads.

When I saw thew result of gmail.new.get.thread_id() in those threads, it evaluated to "undefined" (as opposed to just undefined) and I was certain that was an error/coercion somewhere in the GmailJS code.

However, in those threads, I (like you) found the following node in the DOM:

<h2 jsname="r4nke" class="hP" tabindex="-1" data-thread-perm-id="undefined" data-legacy-thread-id="19a36435ce2f0ff3">  { email subject is here } </h2>

So the ID property is set, but from Google's side it's set to the string-value "undefined", so it's not a coercion error in GmailJS after all. All this while the "legacy" ID is still useful.

Could it be that Google is backtracking on this whole "new Gmail" thread/email-id system?

[arturs-buls]

We got this issue also. We can't use legacy-thread-id because quite a lot of backend is already tied to thread-perm-id.

To "increase our chances" of getting the ID - we use gmail.new.get.email_data(emailDom). Returned object does contain threadId, that we need. But thre is a catch... From my observations - gmail.new.get.email_data() does not return data for first 5 threads. I did dig a little bit and it seems like this library tries to intercept Gmail embedded data with this code, but it looses in race condition (Gmail calls window._GM_setData() sooner, than we get to override that method). I did try to get thread data by different means or try to get _GM_setData overriden earlier, but failed.

We also did implement workaround by converting legacy threadId and just hope it fits (that actual ID is thread-f:... and not thread-a:r...).

Now I just hope that it is bug at Google side that they will fix it. Property with "undefined" string doesn't seem to be intentional (unless they are getting rid of that ID as DOM property entirely)

[arturs-buls]

New developments... data-thread-perm-id is completely gone from DOM.

If user refreshes page on Email - we can get thread_id from gmail.new.get.email_data as it is successfully cached from XHR interception.
if user refreshes on #inbox page - thread-id is present on table items now. When user clicks on any email - that table DOM is still there, so we can query it.

Our current workaround is:

1. Get legacy thread ID from subject el: const legacyThreadId = gmail.dom.email_subject().data('legacyThreadId')
2. Getting that table DOM element by legacy thread ID. `$('.bog [data-legacy-thread-id={0}]'.replace('{0}', legacyThreadId).data('threadId')

[sieppl]

We fixed it by falling back to the old API call, like this:

    this.getThreadId = function () {
        let threadId = gmail.new.get.thread_id();
        if (!threadId) {
          threadId = gmail.get.thread_id();
        }
        return threadId;
    }

[arturs-buls]

@sieppl at this point new.get.thread_id will always be undefined because data-thread-perm-id is completely missing right now

[sieppl]

@sieppl at this point new.get.thread_id will always be undefined because data-thread-perm-id is completely missing right now

Yes, correct. We just wrapped both calls in case the attribute is coming back and not to make any changes to gmail.js. It works for now. We don't know if it is temporary DOM change or not. We have to accept that gmail.js is fragile in its nature and not a reliable API to gmail.