The magic column [tagname] will decorate and auto link tag names when used in a query. This feature relies on the JavaScript processing in the browser. The client-side script assumes it will always get a string. Now try this query:

select id [tagname]
from votetypes

Id is an tinyint in SQL Server and becomes a JavaScript Number when the resultset is send over the wire.

The result is ... column headers only. Not a single row gets rendered. No errors in the UI. But that is a different story in the Developer Console of the browser.

In query.resultset.js the tagFormatter does this:

if (!value || !(value.match(/^[a-z0-9#.+-]+$/) || (isMultiTags = (value.search(/^(?:<[a-z0-9#.+-]+>)+$/) > -1)))) {
    return defaultFormatter(row, cell, value, column, context);

In the above snippet value will be of type Number and unfortunately Number doesn't have methods named match or search so it will fail there with a

Uncaught TypeError: value.match is not a function

(in the minified version the variable name is different).

I guess that if logic needs to include a typeof value !== 'string' so it will for Number columns fallback to the default formatter as it does for other case where it can't workout if the field has a supported tag name.

The workaround is simple: Only use string value columns with the magic column [tagname] to not break the client-side JavaScript.

This post is primarily meant to document the unexpected behavior. For a fix we wait for 6 to 8 weeks till soon™.

  • 2
    ...or /regex/.test(value) which doesn't access any properties of value. Jan 3 at 12:47
  • Another workaround for users is to modify the Number prototype to add .match and .search methods that return false/a falsey value when called. Jan 3 at 12:57
  • Well, are there any tags having numeric names? I don't think there are, so don't think it's a bug and don't think SEDE should be the place to support numeric non existent tags, of all the places. Jan 3 at 13:31
  • 2
    @ShadowWizardChasingStars [1984] on Literature is a synonym to [nineteen-eighty-four]. Jan 3 at 13:37
  • 3
    @ShadowWizardChasingStars it has nothing to do with what the actual tag is. The type is wrong and that breaks code now before it even considers the field / tag content. Not a high prio bug, I give you that. Let's say that I was confused for a few minutes when I stumbled on this issue. And that doesn't happen that often when it comes to SEDE 'features'.
    – rene
    Jan 3 at 13:46
  • @rene I still don't think it's a bug, even having tag name which happens to be a number. Tag name is a string, like display name is string, even if there will be someone calling themselves "1984". Whoever wrote the original code was correct to treat it as a string and I don't see the reason to change it. Jan 3 at 14:09
  • 2
    @ShadowWizard whoever wrote the code should have either accounted for cases where value is not a string (and throw an error) or explicitly disallowed the use of magic columns with number-only columns. In any case, this seems like an uncaught error, which should be fixed (though it's not a high priority as rene mentioned). Jan 4 at 6:55
  • 1
    @ShadowWizardChasingStars any JS code that fails with a TypeError or, worse, SyntaxError, is by definition, a piece of code that has a bug. The bug is that the end user doesn't get any feedback that something went wrong in the first place. Instead, tagFormatter happily trods along to process a type it is unprepared for (not to mention that other formatters have sanity checks for the correct type). Not sure why you insist this is not a bug - it's a textbook one (not an incredibly important one, but still). Jan 4 at 12:59
  • @rene I am at a bit of a loss as to how the tagFormatter factory gets called in the first place. Isn't it guarded by the column.name.toLowerCase() === 'tags' || column.name.toLowerCase() === 'tagname' condition? Jan 4 at 13:03
  • @Oleg when you break the code on purpose, the code will break, it's not a bug. The tag formatter is expecting, well, tag names, giving it numbers is breaking it on purpose. Jan 4 at 13:38
  • 1
    @OlegValteriswithUkraine it is. I deliberately made the mistake to alias the [id] column to [tagname]. The formatters look at the aliased columnames, not the names as is in the original table. It has no way to know that anyway as we are already on the client.
    – rene
    Jan 4 at 17:49
  • @rene don't mind me, I, for some reason, kept missing that it is exactly what you did - aliased a column to one of the column names in the guard :) Given that, it's now obvious why the formatter gets called. Jan 5 at 3:30
  • 1
    @ShadowWizardChasingStars breaking the code on purpose would be fiddling with built-in prototypes or something similar This is just user input, and it has always been untrusted. The bug is not in the formatter per se, it is code breaking on certain user input (aliasing a num. column as a str. column). This is, indeed, a minor bug, but an bug nonetheless. Either built-in column name aliasing should be forbidden, or the code shouldn't rely on the name alone to choose the formatter (especially given that it can check the column type and that it does check the type for other instances). Jan 5 at 6:50


You must log in to answer this question.

Browse other questions tagged .