Closed officialsuyogdixit closed 1 year ago
Uh yeah. I've tested and can confirm.
It seems we still intercept the right XHR calls, but the line-format has changed somewhat, requiring someone to update the parsing-logic:
If we're lucky, this is a quick fix, if not ... The old APIs still seems to work.
If you've engineered your extension to support both old API and new API (like I've done, ahem) and never got around to deprecating the old APIs (like I planned to do, but never did)... chances are you are still going to be OK for now.
While I'll see if I can make a fix for the parser, I can't/won't make any promises about how much effort that is going to take or how soon it will be ready.
For the time being, the quickest way to get your extension "back online" and to recover gracefully is to add a translation layer in your extension to be able to support both APIs versions, depending on what gives you results.
The good news seems to be that it seems to be a small change in the format, mostly indexes being off by 1 (across the board).
That makes it likely that getting a new, working version out is fairly doable.
That said, there are small details here and there it will take some tweaks and testing to make sure everything still works right (for instance to, cc and bcc seem halfway unaffected?),
Will report more when there is more to report.
In the mean time if anyone feels to do the dirty work inside api.tools.parse_fd_request_payload
(and friends) PRs are very much welcome.
Thanks Jostein for figuring out. Waiting for a hero to work for api.tools.parse_fd_request_payload asap ;-).
@josteink : whats the best/preferred way to revert to old API? I am using the "old API", but still getting the same issue, aka event not firing.
I don't think there's an old API fit events you can subscribe too.
You will either have to wait for a fix or help create a PR for your specific part of this bigger issue.
I've done a very quick job at trying to fix the parsing indices for api.new.get.email_data()
and api.new.get.thread_data()
.
It's not ultra thoroughly tested, but I've taken more than a brief glance. From what I can tell, functionality should now be restored to what it was for these API functions.
Published as v1.1.0.
Awesome. Now it works. Hugs.
Actually that still has some bugs in parsing emails embedded at load. There's a v1.1.1
out to fix it, where all NPM dependencies has also been updated to latest to silence some warnings.
Result: gmailjs-node-boilerplate
now loads without Gmailjs runtime warnings, runtime errors or npm security notifications.
Considering this fixed for now.
I think it's broken again, in particular content_html is not working.
Can anyone please provide good news, or if nothing else, stack traces?
This whole thing is killing ne.
It's really strange, it'll work in one box but another. (Google Apps gmail accounts seem to work but newer ones don't.) They must be A/Bing out a change or something like that.
@josteink As for good news, it did seem to work for about a day if that's any consolation.
@josteink Doing some more testing, this error is quite intermittent.
I hate to be the guy who shrugs this off as "works on my machine", but I currently can't see any runtime-errors in my extension.
Can you still reproduce this?
I have updated latest gmail.js but from today both of these functions stopped working. Although, gmail.new.get.email_id() and gmail.new.get.thread_id() works fine. Kindly help asap.