As I understand, from one of the early Gmail product managers, element class names are the most stable of all the 'fingerprints'. The Javascript data structures are quite stable, and the element IDs change pretty much every session.

(Source: I'm the author of the ActiveInbox Gmail extension, and at various times have spoken to Gmail engineers directly).

I agree a service would be a useful thing. A killer bit of value would be if it could workaround Mozilla's addon rules. (We actually stopped publishing on Mozilla addons, because if Gmail changed, we couldn't wait 10 days to be "re-approved" to fix it, and as mentioned by gkoberger, Mozilla really clamps down on dynamic in-app updates).

Ymmv, but if it helps... From the POV of an extension developer, service reliability is critical, and I'm not sure if there's enough GMail extension developers to be customers and make it economically viable?

If there is, I think the ideal service would taint DOM elements with class names to make the important things selectable (rather than a Javascript API to retrieve elements). That way, we could build our own selectors with fail safes to fall back on (and we don't have the security headache of incorporating your dynamically-updated code within our own protected sandbox. We can just share the modified DOM instead).

Whatever you do with it, I'm really impressed with how cleanly you built this kartikt!

Maybe it could just be a JSON file with the xpath of all important elements?

Also maybe it doesn't really have to be a service. It could just be a file on github, where anyone could issue a pull request if gets broken broken. That way way you would essentially crowd source it.

Thank you Andy!

Not sure Google would like this?

Google is aware that people are building tools on top of their UI. If they were against it, they could pretty easily thwart it (e.g. by randomizing their HTML/CSS, or by serve different versions to different users). The fact that they haven't taken time to do this is, I believe, evidence that they aren't hostile to these efforts.

Also, I've personally been in contact with people on the Gmail team about this kind of stuff. They are, generally, supportive, but they're very clear that they'll make no guarantees about stability.

They want to see what works and becomes popular.

Why would they not like this? You still need to open up gmail.com. This is pretty much like you scraping google search results.

Historically extensions for Gmail have often been problematic. A lot of people install them and then forget about them, and if something changes, they blame Gmail and there's errors that can't be reproduced. Plus there's the whole security issue of giving third party code access to your mails.

Neat suggestion. It could totally be uploaded to a cdn where people can simply import it and once a change occurs on Gmail and the script gets updated, everybody benefits.

That probably won't work. The add-on reviewers are very strict about running arbitrary code loaded from somewhere else, and no add-on using it would be approved. (After all, you could change your code and store people's emails.)

That being said, you should be able to use this to load new selector strings for the API:

https://addons.mozilla.org/en-US/developers/docs/sdk/latest/...

http://developer.chrome.com/extensions/webRequest.html

It wouldn't necessarily need to be code. It could just be JSON data with updated selectors, etc. Just make sure you use JSON.parse on it, and there aren't any security issues from just fetching the data.

Yeah, that's what I'm saying -- you can't use this library from a CDN, but you could load JSON.