catching anchor change?

Noit

unread,

Nov 7, 2012, 10:06:47 AM11/7/12

to

hi all when a person clicks on an anchor link does it fire any http-modify or onload event or anything? i was wondering how to detect it (other than adding event listener to url bar for onchange)

Neil

unread,

Nov 7, 2012, 7:35:46 PM11/7/12

to

Noit wrote:

>hi all when a person clicks on an anchor link does it fire any http-modify or onload event or anything? i was wondering how to detect it (other than adding event listener to url bar for onchange)
>
>

It fires a location change progress event (this is of course the event
that the url bar itself listens to).

--
Warning: May contain traces of nuts.

Noit

unread,

Nov 10, 2012, 3:26:08 PM11/10/12

to

A

Ah! Thanks Neil Ill look into that!

Noit

unread,

Nov 13, 2012, 10:28:58 PM11/13/12

to

On Wednesday, November 7, 2012 4:35:47 PM UTC-8, Neil wrote:

Hi Neil. What about for anchor changes in an iframe or frame?
Thanks!

Neil

unread,

Nov 14, 2012, 8:18:11 AM11/14/12

to

Noit wrote:

>On Wednesday, November 7, 2012 4:35:47 PM UTC-8, Neil wrote:
>
>
>>Noit wrote:
>>
>>>hi all when a person clicks on an anchor link does it fire any http-modify or onload event or anything? i was wondering how to detect it (other than adding event listener to url bar for onchange)
>>>
>>>
>>It fires a location change progress event (this is of course the event that the url bar itself listens to).
>>
>>

>Hi Neil. What about for anchor changes in an iframe or frame?
>
>

You get those too, so if (like the URL bar) you're not interested in
them you have to filter them out explicitly, e.g. by using
aWebProgress.DOMWindow == aWebProgress.DOMWindow.top

Noit

unread,

Nov 14, 2012, 10:09:48 AM11/14/12

to

So awesome!! I'll try hooking up the progressListener tonight! Thanks neil!
https://developer.mozilla.org/en-US/docs/Code_snippets/Progress_Listeners

Noit

unread,

Nov 18, 2012, 1:48:06 AM11/18/12

to

Hi Neil you were right. It gets the frame ones too even if the url bar doesnt change. The thing is though, it's very weird. It fires all the time. And it does this weird thing of changing the url bar to blank and you cant click on links in the page.

Also it doesnt show you the previous uri it was before the click.

Is there any other way to catch anchor changes?

Neil

unread,

Nov 18, 2012, 6:08:56 AM11/18/12

to

Noit wrote:

>Is there any other way to catch anchor changes?
>
>

I don't know of one sorry.

Noit

unread,

Nov 18, 2012, 4:20:06 PM11/18/12

to

No problem thanks for the reply.

Does anyone know why the Stop_State is fired multiple times even though pageLoad is fired only once?

Also does anyone know how to get the previous url value before location change?

Noit

unread,

Nov 18, 2012, 4:35:43 PM11/18/12

to

Oh actually the main main problem i'm having is that location change fires even on tab change. I want it to only fire when the page is not unloaded and and anchor changes in the url bar. (IE: Gmail, they dont unload the page but they load a new page. IE2: MDN hot links on right, that just jumps you on the page)

Any ideas on how to do that?

Thanks!

Noit

unread,

Nov 18, 2012, 4:52:11 PM11/18/12

to

Figured it out! There's an optional aFlags property of stateChange, so i just watch for flag of same_document:
https://developer.mozilla.org/en-US/docs/XPCOM_Interface_Reference/nsIWebProgressListener#Location_Change_Flags

Is that the correct way? I did some testing, it also fires when you click back/forwrd only if there were anchors though.

Neil

unread,

Nov 20, 2012, 7:19:06 AM11/20/12

to

Noit wrote:

>Figured it out! There's an optional aFlags property of stateChange, so i just watch for flag of same_document:
>https://developer.mozilla.org/en-US/docs/XPCOM_Interface_Reference/nsIWebProgressListener#Location_Change_Flags
>
>Is that the correct way? I did some testing, it also fires when you click back/forwrd only if there were anchors though.
>
>

This is the new way of doing it, yes. In older versions it wasn't so
easy though, although you could look into using
aWebProgress.isLoadingDocument which is false for an anchor change or
error page while Components.isSuccessCode(aRequest.status) is false for
an error page.

Neil

unread,

Nov 20, 2012, 7:21:54 AM11/20/12

to

Noit wrote:

>Oh actually the main main problem i'm having is that location change fires even on tab change.
>

If you want to track each browser separately then use an all tabs
progress listener which will give you all of the location change events,
not just those for the current tab. (If you want to track the sidebar
too then there is a way of adding your progress listener to the window,
and if you want to catch absolutely everything then you can even add a
global progress listener.)

If you want to track the browser that's currently open, even when the
user has switched away, add your progress listener to that browser
instead of the tabbrowser.

If you want always want to track the browser in the current tab, then
you need to filter out tab switches; aRequest is null for a tab switch.
(I think it might have been null for some obscure error pages but I'm
not 100% sure.) Note that SeaMonkey sets the
LOCATION_CHANGE_SAME_DOCUMENT flag for a tab switch to stop its
doorhangers from dismissing; Firefox has different doorhanger code so it
doesn't do this.

Neil

unread,

Nov 20, 2012, 7:23:25 AM11/20/12

to

Noit wrote:

>Does anyone know why the Stop_State is fired multiple times even though pageLoad is fired only once?
>
>

There are different types of state, so they don't necessarily fire in
the same notification.

>Also does anyone know how to get the previous url value before location change?
>
>

Save it in a variable perhaps?