Editing permanode attrs on web UI updates wrong permanode

52 views
Skip to first unread message

Attila Tajti

unread,
Apr 26, 2017, 2:26:28 AM4/26/17
to Camlistore
I changed a permanode on the web UI that used to be:

$ camtool describe -at 2017-04-26T00:00:00Z sha1-ab849aceb01bcb5050108d9bf571e2bee9115605
{
  "meta": {
    "sha1-ab849aceb01bcb5050108d9bf571e2bee9115605": {
      "blobRef": "sha1-ab849aceb01bcb5050108d9bf571e2bee9115605",
      "camliType": "permanode",
      "size": 562,
      "permanode": {
        "attr": {
          "camliMember": [
            "...list of image permanodes...",
          ],
          "title": [
            "2017-Farsang"
          ]
        },
        "modtime": "2017-04-25T11:02:49.0272824Z"
      }
    }
  }
}

I edited the title on the web UI (removed the slash from it) and noticed saving takes some time. Then I realized that another permanode was changed instead:

$ camtool describe -at 2017-04-26T 05:50:00Z sha1-cd3f555efa12741575c35e0477ca71e5fbf0eaab
{
  "meta": {
    "sha1-cd3f555efa12741575c35e0477ca71e5fbf0eaab": {
      "blobRef": "sha1-cd3f555efa12741575c35e0477ca71e5fbf0eaab",
      "camliType": "permanode",
      "size": 562,
      "permanode": {
        "attr": {
          "camliMember": [
            "...same list of image permanodes as above...",
          ],
          "camliPath:2017-Egerszalók": [],
          "camliPath:2017-Prag": [],
          "camliRoot": [],
          "title": [
            "2017 Farsang"
          ]
        },
        "modtime": "2017-04-26T05:48:22Z"
      }
    }
  }
}

It used to be my publish root:

$ camtool describe -at 2017-04-26T00:00:00Z sha1-cd3f555efa12741575c35e0477ca71e5fbf0eaab
{
  "meta": {
    "sha1-cd3f555efa12741575c35e0477ca71e5fbf0eaab": {
      "blobRef": "sha1-cd3f555efa12741575c35e0477ca71e5fbf0eaab",
      "camliType": "permanode",
      "size": 562,
      "permanode": {
        "attr": {
          "camliPath:2017-Egerszalók": [
            "sha1-8d816ea7c965aedea71491c57fd13aaad86a0eb7"
          ],
          "camliPath:2017-Prag": [
            "sha1-79593689d3c8ee7c394a99107e791f4793be9597"
          ],
          "camliRoot": [
            "publisher-pics"
          ],
          "title": [
            "Publish Root"
          ]
        },
        "modtime": "2017-04-24T10:36:42Z"
      }
    }
  }
}

I wonder if having the camlistore web UI open in the browser while updating it on the server could have resulted in this?

Since this was a problem with my publish root I wanted to fix the problem ASAP so I don't know what version of the web UI was in use in the browser, it could have been either 19972a9 or the 20170405 monthly build.


Attila Tajti

unread,
Apr 28, 2017, 6:30:47 AM4/28/17
to Camlistore
I think I've found the source of this bug.

Pressing cursor right/left on the web UI with an edit box within the permanode tab switches ref to the next/last permanode without loading the attributes of the new permanode.

Steps to reproduce:
  1. Select any permanode on the UI
  2. Switch to Permanode tab
  3. Set focus to any edit box (attribute name or value)
  4. Press cursor left/right
  5. Ref in URL/search bar changes

Camlistore is version c1eeefe from 2017-04-24 with some publisher patches applied.

Mathieu Lonjaret

unread,
Apr 28, 2017, 9:44:50 AM4/28/17
to camli...@googlegroups.com
I see, thanks for the repro.

We should probably at least block navigation when we're editing. I'm
gonna look into it.
> --
> You received this message because you are subscribed to the Google Groups
> "Camlistore" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to camlistore+...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

Attila Tajti

unread,
Apr 28, 2017, 9:51:22 AM4/28/17
to camli...@googlegroups.com
Please note that there are at least 2 bugs if I'm not mistaken:

1. Navigation is enabled in the first place
2. Navigation doesn't update permanode attrs UI

Fixing #1 would solve this issue but it is #2 that seems really dangerous.

Thank you


Attila

On 28.04.2017 15:44:51, Mathieu Lonjaret <mathieu....@gmail.com> wrote:

I see, thanks for the repro.

We should probably at least block navigation when we're editing. I'm
gonna look into it.


You received this message because you are subscribed to a topic in the Google Groups "Camlistore" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/camlistore/uDxRGMnRbds/unsubscribe.
To unsubscribe from this group and all its topics, send an email to camlistore+...@googlegroups.com.

Mathieu Lonjaret

unread,
Apr 28, 2017, 1:40:15 PM4/28/17
to camli...@googlegroups.com
Agreed.
https://camlistore-review.googlesource.com/10026 should fix 2.
Not sure it's the correct Reacty way to do that, but it seems to be
doing the job. PTAL.
I'll see about 1. afterwards.

Attila Tajti

unread,
Dec 20, 2017, 3:43:25 AM12/20/17
to Camlistore
Editing permanode attrs on the web UI still has a problem: cursor left/right still navigates away from the current permanode (and therefore the current edit box).

Camlistore: 2017-12-07-29693e2cc5+
Go: linux/amd64 go1.9.1, cgo=false
djpeg: djpeg available

There were two problems:
#922 (the important one) ensure that changes do not propagate to the new permanode when navigating
#923 (annoyance) navigation should not be enabled when an edit box is active

As far as I understand, both CLs ended up fixing #922 and not #923




On Wednesday, April 26, 2017 at 8:26:28 AM UTC+2, Attila Tajti wrote:

Mathieu Lonjaret

unread,
Dec 20, 2017, 10:18:57 AM12/20/17
to camli...@googlegroups.com
Yes, in https://camlistore-review.googlesource.com/c/camlistore/+/11806
I fixed a bug that is related to the issue, and that needed fixing
anyway:
with this change, if you're now in the middle of editing an attribute
and you navigate away, the edit is not "transferred" anymore to the
page of the prev/next permanode. This prevents you from applying the
attribute to the wrong permanode, like it could have happened by
accident before.
My contention is that fixing this bug made navigating behave
correctly, and therefore it is not necessary, or even desired, to
block navigation when we're editing. Because if you navigate by
mistake there is no other consequence than you having lost whatever
edit you had started, which seems fair.
Do you disagree?

Attila Tajti

unread,
Dec 20, 2017, 10:47:27 AM12/20/17
to Camlistore
I discovered this when editing the title of a permanode. Maybe made a typo or forgot to capitalize something so I wanted to move the cursor to the part of text in question. But this happens also with the main search box.

Is trying to move the cursor within an edit box with the arrow keys considered to be navigation by mistake?

I'm not a UI expert, but IMO if an edit box is focused certain one would expect to have certain events (such as arrow keys with or without modifiers) handled by this edit box only without side effects.

Btw, is there a shortcut to leave the edit box? Eg. in Youtube or Gmail esc does it, but in the Web UI it resets the view.

Mathieu Lonjaret

unread,
Dec 20, 2017, 11:24:23 AM12/20/17
to camli...@googlegroups.com
Ah I see your point now and I totally agree. Arrows should move the cursor when we're editing. Let's reopen the issue.

To unsubscribe from this group and stop receiving emails from it, send an email to camlistore+unsubscribe@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages