Crazy xPath highlighting bug

[designermonkey]

Every time, and I mean every time I type a URL into my address bar with ?debug on it, the devkit automatically applies #xpath-%2F%2F* to the end and highlights every node in that horrid green.

The only way I can get it to stop is to click the link on the side bar. I don't understand why it does this as it's exactly the same URL.

Can anyone reproduce this?

[brendo]

No this doesn't happen for me.

Does this only occur on a particular site/browser/environment?

I have a feeling the debug javascript has some sort of memory to know what your previous xpath was, hopefully @rowan-lewis can shed some light.

[designermonkey]

Right, I have narrowed this down further, as it is still a real headache for me.

Whenever I am on a ?debug page, and I try to change the url in Chrome's address bar to something else, when I hit enter on the keyboard, the xpath currently selected in the xpath input box is highlighted. If I already have an xpath highlighted, the problem doesn't happen.

I think therefore that the javascript is highjacking the enter keypress somehow.

[nickdunn]

I think therefore that the javascript is highjacking the enter keypress somehow.

Seconded, this is a pain the arse. It doesn't happen all the time. But if I am browsing /?debug and then trim ?debug from the URL bar and hit return, sometimes the XPath expression is added as the hash on the end of the URL. I have to remove this by hand, as well as the ?debug and try again, which always works.

Chrome/OSX.

[nickdunn]

For what it's worth, this bug is still really pissing me off. And I havent' figured out how to fix it.

[designermonkey]

I have downed tools and walked away 3 times today from having to enter my urls twice every time

[designermonkey]

This is the offending line (537 devmit.js):

if ((event || window.event).keyCode !== 13)

Why are we looking at the window.event.keyCode property when the event is passed in to the function?

[designermonkey]

Right. It may not be that line, but it is definitely it's function. Changing the function from

input.bind('keyup'...

to

$('#input input').bind('keyup'...

fixes the problem.

[designermonkey]

Nope. no it doesn't.

I'm stumped.

[nickdunn]

I have downed tools and walked away 3 times today from having to enter my urls twice every time

I think you've got issues. I've found that removing the asterisk from the default query, reducing it to // helps.

[brendo]

I can say I have no idea how that XPath script works (I think @rowan-lewis was the original creator).

I think you are on the right track @designermonkey, if ((event || window.event).keyCode !== 13) { looks suspect to me. This is essentially saying that if any event occurs and the keyCode is not 13 (enter), then fire the change event on the input box.

Firing the change event then saves the xpath into the session (via Session.set). This makes window.location.hash equal the encoded XPath and then triggers Session.refresh, which looks like it'll break apart window.location.hash and decode it (wtf we just encoded it?). While this happens, the Session.params variable is set (as is Session.current). Once this has been done, sessionupdate is fired, which then will call Session.refresh again!

The only way this loop is broken is when window.location.hash matches Session.current.

I think it's fair to say this is a cluster fuck and could be greatly simplified =\