When the browser locks up, is the WMEOD window displaying the "Loading new OS data..." message at the top? I can't see anything special about those locations, and other than this initial loading delay when I first highlight a segment in those locations, there's then no further delays as I highlight/select segments at random.

Doh, didn't notice Tim had mentioned Chrome, and since Chrome is normally the last place to look for slow-running scripts I only checked it in Firefox before writing my earlier reply.

I'm also now seeing the sluggish behaviour at those location in Chrome, and I'm 99% sure it's caused by the change in gazetteer name searching I put into 1.18 to fix a problem with city names containing the "-" character - in all three locations you've posted, at least one of the names in the city drop down contain this character, which means the script falls back to a much slower routine to check for city name duplicates...

The fix in 1.18 (and carried through into 1.19) is a temporary fix, there are at least two ways I can avoid having to use the slower search routine at the one-off expense of having to reprocess the gazetteer data files, so a fix will be forthcoming soon.

1.20 has resolved the performance issue with - characters in place names, and the black diamond issue with certain accented characters.

http://userscripts.org/scripts/show/137249

1.21 fixes an issue I've just noticed where the "City name no longer present..." alert would incorrectly appear every time a segment was updated with a placename which included a (county) suffix, and another segment was then highlighted in an area where this placename was still present in the list.

http://userscripts.org/scripts/show/137249

NOTE: The earlier 1.22 release can cause browser deadlock if the name highlighting option is enabled during a lengthy save operation (i.e. more than a handful of changes to commit to the server) - if you've installed 1.22 already, please replace it ASAP with 1.23...

1.23 adds an option to highlight (*) all named segments where the WME name doesn't match up with any of the possible OS names for that segment. This isn't always accurate, partly because the OS data isn't 100% accurate to start with, and partly because the script (currently) doesn't take directional suffixes into account.

Note that, since each visible named segment will generate a seperate OS lookup, it can take a few seconds for the highlighting process to complete on densely populated areas of the map.

Although I haven't exhaustively tested it for compatibility with Timbones' WMECH script, it appears to co-exist OK. The OS highlight should take precedence over any of the WMECH ones, however the script is designed to remove the highlight as soon as a segment is highlighted by the mouse, after which time any WMECH highlight will be applied as expected. OS highlighting is refreshed only when the map is zoomed or panned, or when the option checkbox changes state. Highlighting is also disabled at zoom levels below 4.

http://userscripts.org/scripts/show/137249

* although, given the use of a solid black stripe to mark the offending segments, perhaps describing it as an option to redact badly named segments would be more accurate...

Another lunchtime coding session, another version... 1.24 now ignores ramps when performing the NameCheck scan, and also handles (N)/(S)/etc suffixes - no more mass-highlighting of every motorway and major A road! Also fixed the OS placename auto-selection feature if the previously used name was the 11th "cityname" entry on the drop-down list, and stopped case-correction code from mangling "IV" and "VI" roman numerals present in street names.

http://userscripts.org/scripts/show/137249

It's such a good idea that's been on my wishlist pretty much since I first added the bounding boxes

There are a couple of technical issues though, the first is the amount of processing required to find all the bounding boxes that are visible in the current view, and the second is figuring out sufficiently reliably which boxes don't appear to contain a corresponding segment - many of the boxes for nonexistent roads will still contain segments corresponding to other bounding boxes, and if those segments aren't named then you can't easily discard them.

Right now I'm busy sorting out the latest script breakages caused by the new beta release, once those are out of the way I'll be back onto thinking about adding new features...

Fortunately, it appears that the fixes I've been working on to support the new beta WME also allow WMEOD to work again in this new public version too. If it hadn't been for the combination of local network issues at the weekend, and the ongoing flakiness of the Waze servers, I'd have released the new version already. Barring any further problems here, there or anywhere else, I should however get it onto userscripts later tonight.

1.25 is here... mostly just compatibility fixes for both public and beta WME, but also extends the roman numeral case-correction fix from 1.24 to cover all numerals found in the current OS Locator dataset.

http://userscripts.org/scripts/show/137249

1.26 allows NameCheck to recognise segments that have been renamed correctly but not yet saved...

http://userscripts.org/scripts/show/137249