Tiddlywiki5: Permalink/view should enforce URL

[twMat]

If I've permalinked, say, http://tiddlywiki.com/#HelloThere and manually change the browser url field into e.g asdf... then, applying permalink again does not refresh the URL browser field to reflect this.

Same result for permaview.

I propose clicking a permalink should enforce (refresh?) the browser to show the url (without page reload).

[Jermolene]

Hi @twMat what do you mean by "applying permalink again"? Could you give the precise steps to reproduce on tiddlywiki.com, along with which browser/os you've tried? Many thanks.

[pmario]

@twMat ... did you say Enter after applying asdf.. If not, the browser does nothing. imo a browser problem, not TWs.

[twMat]

I use Win10. In the above I used Chrome. As I now test in FF, I note it is even more problematic (see below).

To reproduce:

1. On http://tiddlywiki.com/ permalink HelloThere via that tiddlers toolbar.
2. manually retype the url browser field to anything else. Do not press enter to actually leave the tw site. In my browsers, To get focus off the browser url field and back on TW, I must click somewhere on the TW.
3. again, in the HelloThere toolbar click permalink.

In Chrome, step 3 does not refresh the permalink if it was previously permalinked and, separately, it did not refresh the permaview if it was previously permaviewed.

In FF, step 3 does not refresh the permalink nor the permaview if either the permalink or the permaview was previously used. I.e if you make a permaview, manually change the url to "afdsdf" and then click eitehr of permalink on any tiddler or permaview, the "asdfasf" remains.

[twMat]

@pmario

did you say Enter after applying asdf.. If not, the browser does nothing. imo a browser problem, not TWs.

What does "the browser does nothing" mean? Should the users perma*-command from within TW not overwrite whatever is seen in the browser url field?

[sukima]

@twMat This is not a TW issue. this is universal behavior of browsers on any site. For example. in GitHub:

1. click on this comment's time field (_X hours ago_).
2. Edit the url as you describe above without pressing enter.
3. Click on a time field again.

You should note that the URL remains the edited version and not the one you clicked on. I really think this is intended behavior.

[tobibeer]

@twMat, you need to manually ESC out of "edit-mode" for the URL field. That is how browsers have come to implement editing the address bar.

[twMat]

@sukima - great comparable example! Maybe you and Mario are right. Still, it seems to me that the/a permaview tool is specifically designed to set the url into [etc] ... so the current behaviour is unexpected. I think links are "subtler" than buttons when it comes to actually perform something.
If it's not possible, then that's a pity.

[twMat]

@tobibeer

you need to manually ESC out of "edit-mode" for the URL field.

So, either ESC _while still_ editing the url - or, after it's edited, click on another link.

[tobibeer]

Mhhh, if you open this page...

http://www.hypergurl.com/anchors.html

...then edit the url without hitting enter and then click the Jump to Bottom link, the url gets updated (in Win/Chrome).

[sukima]

I think the UI maps to the UX like this:

| Action (UI) | Interpretation (UX) |
| --- | --- |
| Edit URL and press ESC | User wishes to cancel the editing. Revert back to previous URL. |
| Edit URL and press Enter | User wishes to confirm the change. Either load the changed URL _or_ in the case of only the hash changing trigger the hash change event and let the page react. |
| Edit URL and loose the focus of the edit bar | User is not done editing the URL and will come back after they finish doing what ever it was that cause them to loose focus on the edit bar. Leave it unchanged. |

[twMat]

Regardless of what manipulating the browser url field is supposed to do, and including if one clicks a page link in some step; When it comes to the TW permalink button there is no ambiguity about what the user wants IMO.

I guess an alternative would be to have the permalink button consistently present the link in some popup or to store in memory, like when copy-pasting stuff.

[sukima]

When it comes to the TW permalink button there is no ambiguity about what the user wants IMO

To me I expect it to link to the permalink, not copy it to the clipboard. I think there should be a different menu item for that. As for the URL bar well I would expect it to work like any other link as described in my comment above.

I am not trying to invalidate you point of view. I only wanted to show that there is other interpretations of what that menu item does. So perhaps there is ambiguity.

[tobibeer]

Hi Mat, I am not sure at all what isn't working for you.

A) When I open this page:

http://www.hypergurl.com/anchors.html

...then edit the url without hitting enter and then click the Jump to Bottom link, the url gets updated (in Win/Chrome).

B) When I open:

http://tiddlywiki.com

...then edit the url without hitting enter and then click the permalink button, the url gets updated (in Win/Chrome).

Both behave exactly the same for me.

[twMat]

@tobibeer

I think you're not doing step 1 as I described it above. You should click the permalink _first_ to get that specific tiddler url, then "asdf", and then _again_ click the permalink.

[tobibeer]

@twMat, you have exactly one option: blame your browsers who don't think it necessary to update the address bar even after you navigated somewhere based on an address change.

[tobibeer]

Other than that:

1. Go to http://TiddlyWiki.com
2. permalink HelloThere
3. edit url but do not hit enter
4. permalink HelloThere again
5. notice how the url is still what you typed
6. focus the address bar and hit ESC
7. voila

TiddlyWiki can do absolutely nothing about that... with "that" meaning: the state where the browser still is in url-edit-mode for you.

But think about it. Imagine you are typing-in some address and some arbitrary page event would steal the address you just wanted to modify / type from underneath your fingertips.

Now you know why browsers willfully preserve the state where they show the address bar exactly how you left it when you didn't finish typing last time.

What is missing here is some indicator by your browser that that address bar is still in edit mode.

[twMat]

Thanks Tobias, but why then _can_ one click on _another_ link or permalink button and have the address field update to this? It seems to be only the previously visible url that cannot be re-displayed by clicking a link or permaview. What makes that url more holy?

And the problem doesn't seem to be the specific "url string" either; if I put in the string http://tiddlywiki.com/#HelloThere into the text of HelloThere tiddler, it does _work_; i.e first click the tiddlers permalink tool, then type "asdf", and click the added string(link). This does make the browser _go_ to that page but still, in the process it does clearly registers the click and adds this url to the urlfield.

[tobibeer]

@twMat, I believe the offending line is this one in updateLocationHash:

https://github.com/Jermolene/TiddlyWiki5/blob/master/core/modules/startup/story.js#L176

if($tw.utils.getLocationHash() !== $tw.locationHash) {

...and maybe it shouldn't be there. Because: If a user clicks 3 times on HelloThere or its permalink feature then it should perhaps also be three times in the history.

[twMat]

@tobibeer - wow, thanks for digging! I hope @Jermolene sees this. A one-line summary of my point is this: A designated permalink/-view tool button is expected to forcefully overwrite anything in the browser url field regardless of what happens to be, or have been, there.

[Jermolene]

@twMat, I believe the offending line is this one in updateLocationHash:

The reason for that conditional is that hashchange events are sent by the browser event when the hash has been changed programmatically. Thus we need to check whether the hash is already at the value we're trying to set before we try to change it.

Generally, I'm a tiny bit astonished at this thread. TiddlyWiki has many areas that could do with improvement and this strikes me as a pretty arcane issue, if indeed it is an issue at all. Is this really what we want to focus on?

[pmario]

Is this really what we want to focus on?

me ... no. We have 80 PullRequest open!

[twMat]

Is this really what we want to focus on?

Agree fully that there's much more important stuff. Still it _is_ an issue and I'm not aware of any way to categorize issues by importance or urgency. If you consider it minute enough for it to be closed, I could live with that even if there probably are other open issues that are similarly small.

[Jermolene]

Hi @twMat it's always OK to raise issues like this; it might have turned out to be something simple and easy to fix.

In this particular case, it's clear that we're seeing interactions with the heuristics that browsers use to determine when the user has finished typing in the address field. It's a behaviour I've noticed changing over the years; in the very early days, one would start typing a URL, need to switch to another tab to figure out part of the URL, and then when one switches back, finding that the partially typed URL has disappeared, or even been navigated to.

Ultimately, I think that behaviour is all in the users interest: they should be sovereign in their own address bar. In the particular context of TiddlyWiki, bear in mind that navigating to a link can change the hash portion of the URL. Do we really want a partially typed URL to be cancelled just because the user clicks a link to consult some information in a tiddler?

[twMat]

Do we really want a partially typed URL to be cancelled just because the user clicks a link to consult some information in a tiddler?

No, not from clicking a plain link. But IMO, yes from clicking a tool seemingly designed to do this.
Maybe it's not possible or worth the effort, that's a bit beyond me to tell.

Thanks for the input on the matter!

[Jermolene]

@twMat can this be closed?