[COMPASS-896] Document how Compass handles special escape sequences in input fields Created: 10/Mar/17  Updated: 10/Jan/24  Resolved: 30/Jun/22

Status: Closed
Project: Compass
Component/s: CRUD, Query
Affects Version/s: 1.6.0
Fix Version/s: None

Type: Task Priority: Major - P3
Reporter: Aleksey Savateyev Assignee: Unassigned
Resolution: Won't Do Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
related to SERVER-20451 Backslashes disappear in the shell Closed
related to COMPASS-1014 Unable to Enter Line Breaks in Strings Closed
Story Points: 5

 Description   

Original Bug Report

1. Try to insert the doc with double backslash in one of the values, for example

{User: "DOMAIN\\someuser"}

2. Try to query for value containing two backslashes

Task on this ticket

  • Document (e.g. in Jira ticket / Google Doc) the behavior for all Compass string input fields
  • Explain background in a few paragraphs: How does escaping work in Javascript / JSON, how does MongoDB store the string in BSON?
Freetext String Input Fields

Document current behavior of "Insert Document" input handling of special character sequences, including

  • single backslash
  • double backslash
  • double-quote
  • newline (backslash followed by n)

See e.g. Single Character Escape Sequences in JavaScript.

Document what was inserted, how it is stored in MongoDB (e.g. inspection via mongo shell or mongoexport) and how it is displayed in Compass.

Fields to check:

  • Insert Document: key names
  • Insert Document: string values
  • Create Database names
  • Create Collection names
  • Query Bar inputs (filter keys and values, project/sort keys only)
  • Create Index: key names
  • Document Validation: key names and string values (regex, ranges, equal/not equal, json view)
  • Delete Database / Collection confirmation dialog
  • Connect dialog fields

For example, for Query Bar:
Document current behavior of "Query Bar" input handling of special character sequences, including the same as above. What was typed, what query was sent to the server (see e.g. mongo logs with db.setLogLevel(1)) and what documents from above were matched with the query.

Future Work

Based on the outcome of the reproduction and documentation of current behavior, we can make a decision on what the desired behavior should be and create appropriate tickets to implement this.

For example:

  • Create COMPASS task ticket to add info sprinkles to explain to user
  • Create DOCS ticket to turn this report into a user-facing documentation
  • Create tickets to resolve inconsistencies between query bar / crud / doc validation / ...
Further Resources and Tools


 Comments   
Comment by Jessica Sigafoos [ 30/Jun/22 ]

Thank you for your feedback! If this issue is still relevant to you, please vote on or file a feature request at https://feedback.mongodb.com/

Comment by Vladimír Čamaj [ 21/Nov/18 ]

Hi, problem with escape slash also appears in using regular expressions. This regexp {"publishDate": {$regex: '^\d{4}\d{2}\d{2}[T]\d{2}:\d{2}:\d{2}[+]' }}  should match the date but match nothing. I am sure it is a bug. RoboMongo resolves it right.  It seems the problem is the \d should be escaped like
d
if it should work.

Comment by Thomas Rueckstiess [ 13/Mar/17 ]

lucas.hrabovsky agree we need more reproduction and docu, but moving it back to "Needs Triage" won't get the work done. If that's what we need, let's put that in the ticket and make it actionable.

Update: done.

Comment by Sam Weaver [ 13/Mar/17 ]

Do you guys need me or Aleksey to provide more info here?

Comment by Lucas Hrabovsky (Inactive) [ 13/Mar/17 ]

thomasr the difference is that the query bar currently uses JSON whereas CRUD does not.

This is a tricky case to handle as double backslash is itself a special character. I've moved this back into "Needs Triage" as I believe more thorough reproduction steps need to be included and documentation of existing behavior.

Comment by Thomas Rueckstiess [ 13/Mar/17 ]

It seems that Compass uses both above interpretations inconsistently in different areas. CRUD (insert/read document) seems to use literal interpretation, while the Query Bar seems to use the special character interpretation. This also explains why the document can't be found any more when searching for double backslashes. You would need 4 backslashes to find it again.

Comment by Thomas Rueckstiess [ 13/Mar/17 ]

sam.weaver, we don't know what the actual behavior should be. There are two choices:

  • Literal interpretation: any characters the user types get inserted literally into the document. For example, typing "\n" inserts a backslash and an n character into the string. It seems the user here expected this behavior.
  • Special character interpretation (like mongo shell): special escape characters or sequences are interpreted and replaced, for example typing "\n" inserts a newline character.
Comment by Sam Weaver [ 10/Mar/17 ]

Actually, this is a different bug. Compass can't handle slashes in values properly.

Example:

Value in shell:

{ "_id" : ObjectId("58c319a69b8e353d7773f362"), "user" : "DOMAIN\\sam" }

Value in Compass is shown as only having a single slash instead of a double slash:
user:"DOMAIN\sam"

Searching for

{user:"DOMAIN\\sam"}

in the compass query bar returns the document showing a single slash which is confusing.

More confusing is that if I insert a document with a double slash in Compass UI, it is stored with 4 slashes in the server:

{ "_id" : ObjectId("58c31929dfc14c1c48bd9fc0"), "user" : "DOMAIN\\\\user" }
Comment by Aleksey Savateyev [ 10/Mar/17 ]

IN the second step I meant searching for any text containing double backslash.

Generated at Wed Feb 07 22:26:19 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.