Discussion on Gmail FavIcon Alerts 3 | Userscripts.org

Bug: Not counting inbox unread, but a label, replied by leopolly @ Fri, 03 Jul 2009 00:13:43 +0000

leopolly — Fri, 03 Jul 2009 00:13:43 +0000

so far, so good...

Compatability with GMail Compactor, replied by Peter Wooley @ Fri, 26 Jun 2009 05:16:33 +0000

Peter Wooley — Fri, 26 Jun 2009 05:16:33 +0000

Support for Gmail Compactor is now back in the script. Go ahead and grab the latest version (3.0.7) and give it a whirl!

Bug: Not counting inbox unread, but a label, replied by Peter Wooley @ Fri, 26 Jun 2009 05:14:47 +0000

Peter Wooley — Fri, 26 Jun 2009 05:14:47 +0000

I believe we solved this problem along with a larger bug in another thread, so grab the latest version (3.0.7) and let me know if the problem is fixed!

Still not fully working, replied by Peter Wooley @ Fri, 26 Jun 2009 02:54:22 +0000

Peter Wooley — Fri, 26 Jun 2009 02:54:22 +0000

The script has been updated! I went to Disneyland for the week and could not think of a solution. I got back and bam, the bug was diagnosed and solved! Thanks again for figuring this out.

Still not fully working, replied by Peter Wooley @ Fri, 26 Jun 2009 02:37:20 +0000

Peter Wooley — Fri, 26 Jun 2009 02:37:20 +0000

Holy crap. getSystemLabelsElement works perfectly. Not only that, it also fixes compatibility with GMail Compactor. I'm going to finalize the script and write up the patch notes. Thanks for taking the time to figure this out, @tschordi, @Moops, and @burnside!

Still not fully working, replied by Peter Wooley @ Fri, 26 Jun 2009 02:27:53 +0000

Peter Wooley — Fri, 26 Jun 2009 02:27:53 +0000

@Moops I gave up on the ID simply because it changed only days after I updated the script, and I've watched it change several times since I started working with the Inbox node.

@tschordi I guess I can't argue with 1.5 years of consistent behavior. I'm going to play with it a bit more, but I think I may just grab the getSystemLabelsElement, assuming it passes all the tests.

Still not fully working, replied by tschordi @ Thu, 25 Jun 2009 19:47:36 +0000

tschordi — Thu, 25 Jun 2009 19:47:36 +0000

Check out the first comment by mikepurvis from Nov 07, 2007 on the API site:

http://code.google.com/p/gmail-greasemonkey/wik...

"AFAICT, gmail.getSystemLabelsElement returns a reference to the DOM element that encloses the topmost navigation box in the left pane, not the green box of user-created Labels. I may have misunderstood the documentation, but it could be clearer which behaviour it's supposed to be."

Seems the behavior of getSystemLabelsElement is correct.

Still not fully working, replied by burnside @ Thu, 25 Jun 2009 16:09:14 +0000

burnside — Thu, 25 Jun 2009 16:09:14 +0000

Well, it's working for me finally! Thanks for working on this script.

Still not fully working, replied by Moops @ Thu, 25 Jun 2009 15:29:30 +0000

Moops — Thu, 25 Jun 2009 15:29:30 +0000

Yeah, I agree, that sounds like an ideal solution. I wonder why Peter gave up on the ID search technique. It looks like it changed from :r2 to :r4 recently, but I'm not sure how often google is likely to change it up.

Still not fully working, replied by Peter Wooley @ Thu, 25 Jun 2009 15:26:05 +0000

Peter Wooley — Thu, 25 Jun 2009 15:26:05 +0000

Wow, something must be wrong with the getSystemLabelElement(). To be honest, they haven't updated the Greasemonkey API in a long time, so it could easily be pointing the incorrect node. However, as it's a published API, I'd rather use a hacky method than rely on something that shouldn't work.

For all intensive purposes, I like both of your approaches (the code's much cleaner), but I'm really curious about the getSystemLabelElement and want to play with it a bit this evening before putting it in the code.

There is some good news, though. I am not sure how, but I replicated the issue on my box at work and the beta code fixed it. So, if nothing else, we should be able to fix the problem with one of these fixes. ;)

Still not fully working, replied by tschordi @ Thu, 25 Jun 2009 07:42:03 +0000

tschordi — Thu, 25 Jun 2009 07:42:03 +0000

Moobs,

i've analysed the getSystemLabelsElement method and in my opinion it isn't the method to get the label box. In my tests it returns the system labels (inbox, starred, sent...).

I have found that in the first poll, the getSystemLabelsElement returns nothing. In the second poll it returns the correct element. This can be the reason why the first poll didn't work (because the SystemLabels doesn't exist with the first poll).

Peter, the question is, why don't we use the getSystemLabelsElement instead of the getNavPaneElement method?

My changes to the this.getSearchElement method from 3.0.6:

this.getSearchElement = function() {
	var element;
	var nav = gmail.getSystemLabelsElement();
	
	if(nav) {
		element = nav.getElementsByTagName('a')[0];	
	}
	
	return element ? element: null;
}

Still not fully working, replied by tschordi @ Thu, 25 Jun 2009 07:06:34 +0000

tschordi — Thu, 25 Jun 2009 07:06:34 +0000

Peter,

you also have a german user, so the search for the inbox text isn't the best method. ;-)

The beta script works for me, too.

Still not fully working, replied by Moops @ Thu, 25 Jun 2009 05:42:59 +0000

Moops — Thu, 25 Jun 2009 05:42:59 +0000

Yes, that works for me. I was just messing around in the same function myself and I noticed that the search returned the link to my first label as gmail loaded for the first time. So I put this check in there:

if(nav) {
  if (gmail.getNavPaneElement() != gmail.getSystemLabelsElement())
    element = gmail.getNavPaneElement().getElementsByTagName('a')[0];
}

Which also works, but I'm not sure if it's more/less of a hack than your approach. I tested with the chat box moved above and below the labels with success. Maybe this gives you an idea anyway.

Still not fully working, replied by Peter Wooley @ Thu, 25 Jun 2009 05:07:40 +0000

Peter Wooley — Thu, 25 Jun 2009 05:07:40 +0000

Hey all,
After peering at the DOM for a bit more, I noticed that one factor hasn't changed: the third parent of the Inbox node is always a span tag. It's a bit esoteric, but grabbing the correct node is simply the most bizarre part of this script. As you're hacking away at the script, would you mind trying a patch? As I can't duplicate the effect, I don't want to publish the changes just yet. With this change, you should be able to revert your workarounds.

I've prepared a beta version of the script, hosted locally, that you can install. This will destroy any changes you've made to your local version. You can take a look at the script and install it here: http://peterwooley.com/projects/greasemonkey/gm...

The changes in the script above are from line 261 to 270 (at least, in my script; yours may differ, depending on any changes to the script), which replaces the this.getSearchElement method with this revised one:

this.getSearchElement = function() {
	var potential, element;
	var nav = gmail.getNavPaneElement();
	
	if(nav) {
		potential = gmail.getNavPaneElement().getElementsByTagName('a')[0];
		
		try {
			if(potential.parentNode.parentNode.parentNode.nodeName.search(/span/i) === 0) {
				element = potential;
			}
		} catch(error) {
			// potential is not valid, allow method to return null
		}
	}
	
	return element ? element: null;
}

The additional check (in the try...catch) is looking for the tag's third parent nodeName. If it's a span tag, we can assume the node we're looking at is the Inbox node. If not, we keep on looking.

If you try this, please let me know if it works or doesn't!

Peter

Still not fully working, replied by Peter Wooley @ Thu, 25 Jun 2009 04:07:07 +0000

Peter Wooley — Thu, 25 Jun 2009 04:07:07 +0000

Ahh, that mysterious Gmail DOM. This has been a thorn in the side of every Gmail script. I'm glad you found this workaround, though I'll do some more digging to see if I can validate that the Inbox tag is the Inbox tag. The trouble with matching /Inbox/ is that it breaks internationalization. As I know we have at least one French user, I'll do my best to keep it.

Still not fully working, replied by Moops @ Thu, 25 Jun 2009 00:42:49 +0000

Moops — Thu, 25 Jun 2009 00:42:49 +0000

tschordi, thanks! That worked for me as well, but I changed it slightly.

if(!self.searchElement) {
  self.searchElement = self.getSearchElement();
  if (!self.searchElement.textContent.match(/Inbox/)) {
    self.searchElement = null;
  }
}

That way it will search each poll only until it successfully finds the Inbox and no more.

Still not fully working, replied by tschordi @ Wed, 24 Jun 2009 11:07:31 +0000

tschordi — Wed, 24 Jun 2009 11:07:31 +0000

Version 3.0.6:

I changed

Line 282-283
if(!self.searchElement) return self.searchElement = self.getSearchElement();

if(!self.searchElement) return self.searchElement = self.getSearchElement(); else self.searchElement = self.getSearchElement();

This searches for the inbox link on every poll. Works for me.

Still not fully working, replied by burnside @ Tue, 23 Jun 2009 02:46:14 +0000

burnside — Tue, 23 Jun 2009 02:46:14 +0000

Nice investigating tschordi. Could you share the 2.6 script with us. I only care about the inbox unread text anyways.

Still not fully working, replied by tschordi @ Sun, 21 Jun 2009 09:18:34 +0000

tschordi — Sun, 21 Jun 2009 09:18:34 +0000

The difference was the favicon script version. 2.6 works because the search method for the unread count was based on the inbox text. Version 3.0 uses the getNavPaneElement from the GMail Greasemonkey API. The first link under this element should be the inbox link.

I debugged the search method in 3.0 and it doesn't return the inbox link. It returns the first link from my quick links box.

Mysterious...

It could be that the navigation links aren't the first elements at the time when the poll event is fired first.

Still not fully working, replied by tschordi @ Sat, 20 Jun 2009 15:14:11 +0000

tschordi — Sat, 20 Jun 2009 15:14:11 +0000

Regularly I use 3 different PCs. I have all updated to Firefox 3.0.11 recently. One installation works! I try to search for the difference between these three installations/profiles.

Still not fully working, replied by burnside @ Fri, 19 Jun 2009 18:33:36 +0000

burnside — Fri, 19 Jun 2009 18:33:36 +0000

That is strange why Google Reader is fine but not GMail. :(

Still not fully working, replied by Moops @ Wed, 17 Jun 2009 22:35:59 +0000

Moops — Wed, 17 Jun 2009 22:35:59 +0000

I see the red icon all the time with 0/1/many new mails. Refreshing the page has no effect either. The only thing that changed on my end was the FF update. I have since updated this script though. The GReader script is working great still.

Still not fully working, replied by tschordi @ Wed, 17 Jun 2009 17:41:38 +0000

tschordi — Wed, 17 Jun 2009 17:41:38 +0000

I've inserted the source code of the favicon script in a script tag in the head. right click --> edit html...
Then I execute following code at the firebug command line:
gmonkey.load('1.0', function(gmail) { gfia(gmail); });

It works for me.

I deactivated all addons except firebug and greasemonkey. Still no luck... It must be related to the Firefox 3.0.11 update.

Still not fully working, replied by Peter Wooley @ Wed, 17 Jun 2009 07:08:09 +0000

Peter Wooley — Wed, 17 Jun 2009 07:08:09 +0000

I've now tested on an account with every lab feature enabled (save for Hide Unread Count) and set to different languages with no luck in replicating the behavior.

Besides me, is there anyone out there experiencing the bug only some of the time? For those without any functionality, is there anything besides the Firefox 3.0.11 update that changed in your environment?

@tschordi I'm curious, how did you go about loading the script through Firebug?

Still not fully working, replied by tschordi @ Tue, 16 Jun 2009 19:03:23 +0000

tschordi — Tue, 16 Jun 2009 19:03:23 +0000

It doesn't appear that this is an issue due to DOM changes. I have inserted the FavIcon script in the DOM through Firebug and it works! I use script version 3.0.6. I have recently updated because i expected this solved the issue.