Had fun this afternoon figuring out where weird subtle misbehavior in a client site's menus had come from, only to realize that syntax errors in extlink.js were tripping up Javascript sitewide. It's simple enough to prevent this from affecting everything else like I did, but I'm not sure what you'd want to do vis a vis error reporting via JS.

if (Drupal.settings.extlink.extInclude) {
try {
extInclude = new RegExp(Drupal.settings.extlink.extInclude.replace(/\\/, '\\'));
} catch (err){
}
}

// Extra external link matching.
var extExclude = false;
if (Drupal.settings.extlink.extExclude) {
try{
extExclude = new RegExp(Drupal.settings.extlink.extExclude.replace(/\\/, '\\'));
} catch (err){
}
}

Comments

elachlan’s picture

elachlan CreditAttribution: elachlan commented

This was supposed to be fixed by validating the regex before saving. See #1434104: Validate regexs (to prevent Javascript / regex problem: invalid quantifier).

Can you let us know if the regex is not being validated properly?

lejonsson’s picture

lejonsson CreditAttribution: lejonsson commented

Without having any technical details, I also still have problems with js using 6.x-1.15, some went away with the update so I thought it was all fine, but then I notices other js-functions still not working.

elachlan’s picture

elachlan CreditAttribution: elachlan commented

If you can provide a javascript error that would be fantastic.

elachlan’s picture

elachlan CreditAttribution: elachlan commented
Status: Active » Postponed (maintainer needs more info)

I'll postpone this until I get more information in regards to the JS error.

I do think it could be worth while to add a try block, but it ultimately up to quicksketch. It would suppress any errors, which might be undesirable for debugging larger issues with external links.

It would be nice if JS errors didn't clash with other modules/site functionality though.

jstange@bluewatermedia.com’s picture

jstange@bluewatermedia.com CreditAttribution: jstange@bluewatermedia.com commented

Hey, and I'd forgotten about this bug report...

I see that bad data in those fields is getting caught by validation. I suspect when I originally ran into this, it was data that had been entered prior to a module update being applied, so it slipped past that goalie.

You'll have to comment out the validation extlink.module to reproduce this, but other than that it's trivial- just add a syntactically incorrect regular expression to the Include or Exclude field under "Pattern matching." If I drop a paren from an otherwise-correct pattern and save, I'll get this in the Javascript console on subsequent pageloads:

[13:31:58.331] SyntaxError: unterminated parenthetical @ https://testsite.com/sites/default/files/js/js_bd8814e2a3e60c4e1c0a8d6cc...

...and of course any Javascript past that point in the aggregated JS fails to load, and lots of random unrelated things break.

Sticking a try{ } around it seems like the right thing to me, even if the input fields are theoretically being validated. The question is what to do with errors once you catch{ } them. I'm not sure what best practice is for where, how, and how loudly to report Javascript errors in a D6 module.

elachlan’s picture

elachlan CreditAttribution: elachlan commented
Issue summary: View changes
Status: Postponed (maintainer needs more info) » Closed (won't fix)

I think it is best to leave it. If your regex is broken, you want to be told about it. You don't want it hidden.

That being said, the regex is being validated before being saved. So this use case shouldn't really happen and if it does, people should be able to work out what the problem is.