5 ms·

It would be amazing if this were a service. Easier said than done, I know -- but, basically this but have it check a JSON file every few hours and gets the upda

It would be amazing if this were a service. Easier said than done, I know -- but, basically this but have it check a JSON file every few hours and gets the updated selectors. (For people who don't know, all GMail's classes and IDs are things like '.xb3', and they change often.) Having worked on Mozilla Add-ons for a long time, one of the biggest problems was by the time any G-Mail add-on was approved, it was already out of date again. API calls, when done correctly, are allowed by both Chrome and Firefox -- this could be a good solution. (You could easily charge a few bucks for this, and even contact Firefox + Chrome about making sure the reviewers allow it. Market it as "cutting down on their time" since there will be less to review.)

kartikt 13y ago
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.
- gkoberger 13y ago
  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/modules/sdk/request.html https://addons.mozilla.org/en-US/developers/docs/sdk/latest/... http://developer.chrome.com/extensions/webRequest.html http://developer.chrome.com/extensions/webRequest.html
  - joshuacc 13y ago
    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.
    - gkoberger 13y ago
      Yeah, that's what I'm saying -- you can't use this library from a CDN, but you could load JSON.
deleted 13y ago
[deleted]
deleted 13y ago
[deleted]
loceng 13y ago
Not sure Google would like this?
- csallen 13y ago
  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.
  - loceng 13y ago
    They want to see what works and becomes popular.
- yeukhon 13y ago
  Why would they not like this? You still need to open up gmail.com. This is pretty much like you scraping google search results.
  - Hurdy 13y ago
    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.
deleted 13y ago
[deleted]
andymitchell 13y ago
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!
- kartikt 13y ago
  Thank you Andy!
- ma2rten 13y ago
  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.

kartikt 13y ago

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.

gkoberger 13y ago
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/modules/sdk/request.html https://addons.mozilla.org/en-US/developers/docs/sdk/latest/... http://developer.chrome.com/extensions/webRequest.html http://developer.chrome.com/extensions/webRequest.html
- joshuacc 13y ago
  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.
  - gkoberger 13y ago
    Yeah, that's what I'm saying -- you can't use this library from a CDN, but you could load JSON.

deleted 13y ago

[deleted]

deleted 13y ago

[deleted]

loceng 13y ago

Not sure Google would like this?

csallen 13y ago
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.
- loceng 13y ago
  They want to see what works and becomes popular.
yeukhon 13y ago
Why would they not like this? You still need to open up gmail.com. This is pretty much like you scraping google search results.
- Hurdy 13y ago
  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.

deleted 13y ago

[deleted]

andymitchell 13y ago

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!

kartikt 13y ago
Thank you Andy!
ma2rten 13y ago
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.