Show record in history unescaped

[wagnerand]

I often need to copy values from the history view. The history shows the raw JSON entry, which might contain escaped values.

It would be nice to have an option to show the unescaped values, so I can copy and paste them somewhere else and use them without unescaping.

[leplatrem]

Do you have an example? I can't easily reproduce. Is it from the full diff view or the table rows?

[wagnerand]

It's anywhere we show JSON for a record, for example .../admin/#/buckets/staging/collections/addons/history:

[leplatrem]

Thanks! ...I didn't have these black slashes in mind.

[leplatrem]

After looking at this more concretely, I don't really understand what could we do here.

If I look at the data here https://firefox.settings.services.mozilla.com/v1/buckets/blocklists/collections/addons/records?_limit=5 with different tools, they all show this JSON the same way.

I feel confused, what would you expect instead?

If you refer to copy/pasting regexp itself, then stripping out the leading/trailing slashes should work:

>> new RegExp("^\\{abc\\}$").test("{abc}")
true

These slashes are part of the data, I don't think it makes sense to strip them out from the admin UI perspective. Please help me figure out how we can help here :)

[wagnerand]

Is there a way to show the data not in raw JSON but in a form that doesn't contain escapes because of JSON?

If you refer to copy/pasting regexp itself, then stripping out the leading/trailing slashes should work:

>> new RegExp("^\\{abc\\}$").test("{abc}")
true

These slashes are part of the data, I don't think it makes sense to strip them out from the admin UI perspective. Please help me figure out how we can help here :)

That wouldn't work, since curly braces are not just at the beginning and end of the string. The blackslashes are indeed part of the data, but JSON escapes the backslash itself, leading to double backslashes.

So, if the raw data is \{abc\}, the view presents it as \\{abc\\}.

[leplatrem]

Ok, I think I get it :)

I found a way to obtain the representation you want using Chromium DevTools (couldn't find any in Firefox)

So the component could show the JSON data like this:

{
  data: {
    id: "055d2447-c7b7-49a2-bb27-b1c09a592f32",
    last_modified: 1566422986828,
    guid: "/^((\{fb2cbb8e-a6f9-464b-97c7-aca958a404d6\})|(\{8cc60aa4-fceb-4a74-bef4-bbbdc23b85fb\}))$/",
    prefs: [],
    schema: 1566419767711,
    details: {
      bug: "https://bugzilla.mozilla.org/show_bug.cgi?id=1573237",
    },
    enabled: true,
  }
}

[glasserc]

Also, per our discussion on Zoom yesterday, it could display it like this:

id: 055d2447-c7b7-49a2-bb27-b1c09a592f32
last_modified: 1566422986828
guid: /^((\{fb2cbb8e-a6f9-464b-97c7-aca958a404d6\})|(\{8cc60aa4-fceb-4a74-bef4-bbbdc23b85fb\}))$/
prefs: []
schema: 1566419767711
details:
    bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1573237
enabled: true

But to be honest I still don't really understand what the use case is for copying and pasting this data. Why are there the / slashes at beginning and end? It seems like a regex literal somehow got into a string (rather than normal regex string syntax). Where are you pasting it into? I guess not a JS console, because there the syntax would already be correct.

[wagnerand]

But to be honest I still don't really understand what the use case is for copying and pasting this data.

The use case for this is a reviewer verifying that the blocked IDs pattern is correct.

Why are there the / slashes at beginning and end? It seems like a regex literal somehow got into a string (rather than normal regex string syntax).

The guid field is a string. On the page for creating the record, the following label is shown: In case of a RegExp, the value must conform to the JavaScript syntax, enclosed within slashes (/).

Where are you pasting it into? I guess not a JS console, because there the syntax would already be correct.

I usually use a tool like https://regex101.com/.

[glasserc]

OK. I took a look at the data in the collection. I didn't realize that this field can either be a string literal, or a regular expression. I guess the answer to my question is "we use slashes to identify that the string is meant to be a regular expression". Regular expressions are handled by the code at https://searchfox.org/mozilla-central/source/toolkit/mozapps/extensions/Blocklist.jsm#1163-1165 and it seems like we use the slash syntax to even allow us to combine flags into the same string, although I can't really see a use for that (almost any flag I could think of would be basically useless in this context, and I don't see any uses of these flags in the data anywhere).

Given the fact of having to support old clients indefinitely, I guess I can't propose changing the data format. In general, you could use a JavaScript console to parse the JSON strings, as in Mat's example. I guess we could still do that, either using eval to parse the whole regular expression literal, or by doing something like s = [pasted from admin]; new RegExp(s.slice(1, s.length - 1)). Alternately you could just do console.log to get the textual value of the string. Finally, I still think it makes sense to display data as a textual string rather than encoding it as JSON. We already do this on e.g. the admin front page or the table-of-rows view.

I usually use a tool like https://regex101.com/.

Interestingly, this tool does support copying and pasting regular expression literals, although https://www.regextester.com/, https://regexr.com/, and https://www.freeformatter.com/regex-tester.html all don't.

[alexcottner]

@wagnerand - Hello, I've picked up this issue. The UI has changed quite a bit since it was created, so I'm not sure if we're having the same problem. these days

Below are some updated screenshots showing what it looks like right now, and a couple options for what it could look like. Do any of these look reasonable?

The hybrid change doesn't replace linebreaks like the first one does. We do have some multi-line fields so this could be confusing. Here is another option where we render the linebreaks. It looks a bit wonky without rendering spaces to align things properly, but adding spaces that aren't there probably goes against what we're trying to do here.

Wanting to make this UX change makes sense to me. But I think we're bumping against a language/format limitation. If none of the above options are good, would a button that returns the raw property value to your clipboard be better? If you're clicking on a removed line you'd get the old value, and on a new line you'd get the new value. Not sure how much effort that would be to make, but it might be better than these options.

[wagnerand]

@alexcottner Hi! The add-ons team is no longer using kinto-admin directly.

[alexcottner]

Thanks for getting back to me! In that case I think we'll be closing this issue as we don't have anybody else tracking it and the UI has changed significantly since it was opened.