Fix the navigation_count function and selector

[stevenirby]

This fixes two of the methods api.helper.get.navigation_count and api.get.storage_info. It returns a fair amount of data back:

{storage_info: 
{used: 14.32, total: 15, percent: 95},
unread_draft_emails: 152
unread_emails: {inbox: 882, drafts: 152, spam: 0, forum: 0, update: 0, …}
unread_forum_emails: 0
unread_inbox_emails: 882
unread_promotion_emails: 7
unread_social_emails: 0
unread_spam_emails: 0
unread_update_emails: 0}

I'm trying to target the aria labels and accessibility tags, as I think it's a better move to try to parse the page like https://testing-library.com/ library does testing. Looking at the page like a real user or a screen reader would, rather than targeting class names or such, which is a cat-and-mouse game.

I'm also doing console.warns when things aren't found for easier debugging. Throwing an error or console.error seemed a bit too much.

I'm totally open to any advice or feedback!

[josteink]

Ive given the PR a test-run on a few different accounts:

• Regular gmail.com account
• OG, grandfathered "Google Apps" account
• Paid, company GSuite account

Results below.

Regular gmail.com:

Unread-fix confirmed working.
Storage_info() doesn't work though. (Output is all zeros)
Tested with English US locale.

OG, grandfathered "Google Apps" account.

Unread-fix confirmed working.
Storage_info() doesn't work though. (Output is all zeros)
Tested with Norwegian and English UK locale.

Paid, company GSuite account:

Unread-fix partially working. Better than before, but produces console-warnings for all counters not Inbox, and provides 0 as result, even for labels which has unreads.
Storage_info() doesn't work though. (Output is all zeros)

[josteink]

I see storage_info() is implemented using a regexp on text values.

Below are the texts Ive seen for my accounts:

• Using 0.66 GB
• 6.57 GB of 17 GB used
• 2.04 GB of 15 GB used ("2,04 GB av 15 GB er brukt" in Norwegian)

Based on the regexp used, Id say the reason for the failure is assuming "X of Y" format and assuming percentage at the end.

Maybe you can relax the conditions slightly?

[stevenirby]

@josteink thank you so much for testing!

One big issue is that a lot of data isn't in the DOM until the page is fully loaded. After gmail.observe.on('load', () => {}) is done. I believe the correct fix is to add more watchers to wait until more of the DOM is loaded?

Unread-fix partially working. Better than before, but produces console-warnings for all counters not Inbox, and provides 0 as result, even for labels which has unreads.

Do you think it should return undefined instead? I didn't want to break any scripts out there using this.

Based on the regexp used, Id say the reason for the failure is assuming "X of Y" format and assuming percentage at the end.
Maybe you can relax the conditions slightly?

Will do.

[josteink]

What might help make things easier for you is to separate data-fetching from data-processing into 2 different functions.

That way you can unit-test the processing and just add my real world examples above as test-cases.

That may sound complicated at first, but I think it will help you solve this faster and better.

[josteink]

I dont understand this change. Previously the function would return a jQuery element (as formalized in the gmail.d.ts typescript definitions), but now you are returning a number?

The documentation also clearly states that this function should return DOM content.

DOM

These methods return the DOM data itself

gmail.dom**.inboxes()**
gmail.dom**.inbox_content()**

So what's the idea behind this change?

[stevenirby]

@josteink Opps! I didn't mean to push this to the PR. Actually, I'm just going to close the PR.

Sorry about that.

[josteink]

This regex will still only work for english locales, and wont be applicable to non-english users.

Please see earlier feedback on this point.