Please help test the new desktop pre-release

mic704b · 2020-03-06T05:24:42.064Z

Thanks. Confirm works now on master (was broken in v187).

tessus · 2020-03-06T05:27:39.912Z

That’s weird, because the code for geo-location hasn’t changed between 187 and 190.

mic704b · 2020-03-06T06:40:35.655Z

Yes, I noticed. I think it was a side-effect of something else (new note stuff).

sciurius · 2020-03-06T07:36:56.177Z

https://github.com/laurent22/joplin/issues/2646# is getting worse…

memophen · 2020-03-06T11:27:14.174Z

As far as the issues mentioned by me are concerned, these are my findings in 1.0.190:

[x] The generated HTML is identical to v1.0.179’s.
[ ] H1: the style for #rendered-md H1:first-child is still missing. As a consequence, there is 1.2em whitespace above the first header of the note.
[x] H5-2 and H6-2 are lightgreen, as in 1.0.179.
[x] The word “red” is red, as in 1.0.179.
[x] <mark>bla</mark> marks “bla”, as in 1.0.179.

So one of my issues is still open.

laurent · 2020-03-06T11:59:04.179Z

memophen:

`` H1: the style for #rendered-md H1:first-child is still missing. As a consequence, there is 1.2em whitespace above the first header of the note.

I removed this CSS as the logic was making it remove the top margin from lists and probably other elements too.

If someone has a clue about CSS and know how to implement this, I'd accept a PR. The idea is to remove the top margin from H1 and other elements when they are on top of the page (because there's already a margin there).

image1634×982 200 KB

memophen · 2020-03-06T13:12:12.669Z

laurent:

If someone has a clue about CSS and know how to implement this

I'm not 100% sure what you mean by "this", but I have a suspicion. The original CSS was:

#rendered-md h1:first-child,
#rendered-md h2:first-child,
#rendered-md h3:first-child,
#rendered-md h4:first-child,
#rendered-md ul:first-child,
#rendered-md ol:first-child,
#rendered-md table:first-child,
#rendered-md blockquote:first-child,
#rendered-md img:first-child,
#rendered-md p:first-child {
  margin-top: 0;
  padding-top: 0;
}

This covers all h1..p elements that are a first child of some element AND are also a descendant (in whatever degree) of #rendered-md. That's a bit too much. If it is replaced with:

#rendered-md > h1:first-child,
#rendered-md > h2:first-child,
#rendered-md > h3:first-child,
#rendered-md > h4:first-child,
#rendered-md > ul:first-child,
#rendered-md > ol:first-child,
#rendered-md > table:first-child,
#rendered-md > blockquote:first-child,
#rendered-md > img:first-child,
#rendered-md > p:first-child {
  margin-top: 0;
  padding-top: 0;
}

then it will cover all h1..p elements that are the first direct child of #rendered-md. That's exactly what we want, isn't it?

memophen · 2020-03-06T16:28:33.307Z

This is really weird! My experiments have been executed on v1.0.179, and the CSS works there as might be expected.

On v1.0.190 however, the greater-than sign in the selectors part make the entire rule invalid. Even one > operator is fatal. I have no explanation for this. The rules that follow (coloring the H5 and H6) still work, so the <style>...</style> block has not completely been blown up.

This concerns only the CSS specs in the note itself. When I copy them to userstyle.css, they work again as expected. So there must some extra intermediary interpretation of style blocks embedded in notes that is malfunctioning now. New issue!

laurent · 2020-03-06T16:30:21.142Z

memophen:

This concerns only the CSS specs in the note itself. When I copy them to userstyle.css , they work again as expected. So there must some extra intermediary interpretation of style blocks embedded in notes that is malfunctioning now. New issue!

Yes this is fixed, it's because the style was incorrectly escaped. The fix will be in the next release.

laurent · 2020-03-06T16:30:55.856Z

memophen:

then it will cover all h1…p elements that are the first direct child of #rendered-md. That’s exactly what we want, isn’t it?

Yes thank you, that works, so I'll re-enable it in the next release.

laurent · 2020-03-06T23:29:05.942Z

New pre-release with more fixes:

https://github.com/laurent22/joplin/releases/tag/v1.0.192

I think we’re getting close to production ready release but if you still notice some issue, please post here.

Security: Changed default encryption method to CCM
Fixed: Handle invalid UTF-8 data when encrypting (#2591)
Fixed: Fixed top margin issue on note rendering
Fixed: Fixed issue with style embeded in notes

laurent · 2020-03-07T00:36:20.101Z

Note that due to the encryption method change, non-updated clients won’t be able to decrypt the notes created by this new version (assuming you use E2EE). All clients are going to be updated soon but something to keep in mind.

If you try to sync these newly encrypted notes with a non-updated client, the notes will simply remain encrypted on that client, and will be decrypted when you upgrade.

tessus · 2020-03-07T04:49:03.394Z

laurent:

Note that due to the encryption method change, non-updated clients won’t be able to decrypt the notes created by this new version (assuming you use E2EE). All clients are going to be updated soon but something to keep in mind.

This would have been a good point to increase the minor. So that all clients with the same minor are compatible.

bedwardly-down · 2020-03-07T05:08:39.338Z

With how many pre-release builds, I’d definitely expect Joplin 1.1.0. Unless you’re planning on going the Vim route and be up to 8.1.9253 or something crazy before incrementing the minor version. Ha

xplosionmind · 2020-03-07T09:58:17.095Z

Hello everybody, I’m experiencing the graphical bug in the screen recording below since I updated Joplin app on MacOS 10.15.3 to v1.0.189. Right now I’m running v1.0.192, always on MacOS.

Bug description

When I’m scrolling down in a note, even if it’s short and it completely fits in the page, I have a white blank margin coming up from below. As you can see, even when not scrolling, there’s also a persistent scrollbar on the right.

Screen Recording is here

If it’s necessary I can create an issue on GitHub.

Let me know, thanks for your help @laurent!

laurent · 2020-03-07T09:59:55.916Z

@xplosionmind, there was no attached screen recording.

xplosionmind · 2020-03-07T10:03:25.983Z

laurent:

@xplosionmind, there was no attached screen recording.

I'm sorry, I uploaded the video but probably Discourse doesn't support it. Now I fixed it inserting a link to an unlisted YouTube video.

dkebler · 2020-03-07T15:05:12.951Z

I am using 179. Will there be non revertable changes to the database? i.e. can I just swap back to previous version if need be? If so I’ll give it a spin as it’s easy for me to swap versions the way I have it installed.

bedwardly-down · 2020-03-07T17:36:19.987Z

dkebler:

Will there be non revertable changes to the database?

I can definitely answer this. I'm not sure what's been changed but all versions past at least the draft version 182 all had where i needed to delete and rebuild my config directory when moving back to 179

memophen · 2020-03-07T21:43:43.358Z

Ah, always good to be reminded to start with a blank ~/.config/joplin-desktop/ (after having it backed up some way) in case of a rollback. I have read various instructions for such cases on this forum, but I would very much appreciate a complete guide in one place for all platforms.

Currently, I do all my experiments on the Mac, because rolling back is so easy there: just rename/move the ~/.config/joplin-desktop/ folder, copy the old Joplin version to /Applications/ (overwriting the newer version), run it, define the wanted configuration settings again (actually the most annoying operation is this procedure), copy the old userstyle.css and userchrome.css to the new ~/.config/joplin-desktop/ folder, exit Joplin, rerun it, and find that everything works again as it did before. And oh yes, the backup of the configuration can now be deleted.

I wouldn’t know how to downgrade on Windows or Linux. And mobile is completely dark matter to me.