[Script] WME Validator v2020.11.1 (PLACES BETA)

[Glodenox]

If the verified tag is part of the segment, it should be possible for Validator to pick it up and expose it in the custom templates. So that would be an interesting addition for countries that have imported speed limits indeed.

[Glodenox]

Even though it was slightly off-topic, it was still useful for the topic. So no harm done

EDIT: ah, didn't notice that you accidentally wrote "TB" instead of "Validator". Meh.

[Glodenox]

I have the same issue as jdelosa. Would it be possible to hide that bubble somehow? They were handy when I first used validator, but by now it is just taking up space and even hiding useful information.

[Glodenox]

The issue of changing class names and such can be sort of solved by having a fallback scenario in case you can't find the container. The fallback could be positioning it as before or perhaps even with absolute values in the bottom left corner or so.

I've even got 3 lines of tabs and don't find it too bad. I've been thinking about a way to make the tab list more compact and intend to experiment with it a bit, but these tabs are more compact than each script taking up their own bit of space on the left.

[Glodenox]

As of the past couple of days, WME Validator has been refusing to load for me. The browser console gives this error:

Code: Select all

TypeError: invalid assignment to const `unsafeWindow'   WME_Validator.user.js   line 129 > eval:1:277

Browser: Firefox 44.0b2
Greasemonkey version: 3.6

I've had this happen to another script as well (WME LiveMap Closures) where I could just remove the whole section on unsafeWindow as the script didn't use it anywhere. For WME Validator I've had to do some more digging and converting, but the following segment seems to be the culprit:

Code: Select all

    try {
      'object' === typeof Components.interfaces.gmIGreasemonkeyService && (b = !0)
    } catch (a) {
    }
    void 0 != typeof unsafeWindow && b || (unsafeWindow = function () {
      var a = document.createElement('p');
      a.setAttribute('onclick', 'return window;');
      return a.onclick(null)
    }());

The whole setAttribute trick to get an unsafeWindow on Chrome no longer works and can therefore be removed. For the code that uses Components I receive the error in the browser console that it is no longer supported in Firefox and will be removed soon. Luckily, unsafeWindow is available and doesn't need to be overwritten. Sadly enough, Google Chrome then can't find unsafeWindow any more, so there'll be issues there.

[Glodenox]

FYI: I've slightly updated my previous reply about WME Validator no longer working in the next version of Firefox.

While spitting through the code, I noticed that WME Validator adds its own tracker to Google Analytics. What's the purpose of this tracker?

[Glodenox]

I've warned about this and even PM'ed the author about this with the simple fix that is needed. The script is now failing on a bit of code that doesn't even work any more.

It is related to the removal of the Components object as of Firefox 44. This makes the logic so that the script tries to overwrite unsafeWindow (as it wrongly expects it's not running Firefox), which then results in an exception being thrown.

[Glodenox]

Yup, seems to be working as intended again. Thanks!

[Glodenox]

Hmm, I've recently started having problems having WME Validator to load in Firefox 45.0 when I'm already logged in. This happens on two different computers.
The only message WME Validator gives in the browser console is "WME Validator v1.1.16: waiting for login...".
Only when I log out and log in, WME Validator loads fine for that session as the login gets triggered. So at least we know it isn't related to that. As this looks like a racing condition somewhere, I tried fixing it by putting the script to run before or after all other scripts, but neither action changed anything.

I personally use the following bit of code to check whether I still need to wait on a user login and that seems to work fine:

Code: Select all

// preceded by a check on whether the element with id user-info exists
if (!Waze.loginManager.hasUser()) {
  Waze.loginManager.events.register("login", null, exportFunction(init, unsafeWindow));
  Waze.loginManager.events.register("loginStatus", null, exportFunction(init, unsafeWindow));
  return;
}

To be absolutely safe that the event doesn't happen to be triggered between the check and registering the listener, you could also check hasUser again before actually returning, but in the time I've been using this bit of code I haven't had any issues yet.

EDIT: I've noticed that enabling the WME Toolbox makes Validator work again. Toolbox probably slows down Firefox enough for Validator to pick up that someone is already logged in. That's not really a solution though.

[Glodenox]

Guys, isn't there some USA-specific thread about Validator in which such discussions can take place? Right now it's just cluttering this topic.

Another (easier) issue: would it be possible to fix the FontAwesome icons? This is what WME Validator looks like at the moment:
[ img ]

The problem is that the classes used to get FontAwesome icons were changed a month or two ago. You now need to apply the "fa" class and the icon-specific class. I've gone over the classes in Validator for you to make it easier:
icon-check -> fa fa-check-square-o (empty: fa fa-square-o)
icon-filter -> fa fa-filter
icon-search -> fa fa-search
icon-user -> fa fa-user
icon-wrench -> fa fa-wrench
icon-question-sign -> fa fa-question-circle
icon-list -> fa fa-list
icon-magic -> fa fa-magic

After these changes (I couldn't find any other occurrences of "icon-"), Validator looks like this again:
[ img ]