search

openstyles / stylus

Stylus - Userstyles Manager
https://add0n.com/stylus.html
GNU General Public License v3.0
5.43k stars 304 forks source link

[Bug] Publishing a style to userstyles.world doesn't set the updateUrl #1667

Open denilsonsa opened 1 year ago

denilsonsa commented 1 year ago

Bug Report

Bug Description

When installing a style from USW (userstyles.world), Stylus will set the updateUrl, and thus that style will be automatically checked for updates. However, when publishing a style to USW, the updateUrl will never be set.

As a workaround, we can visit the published style and click to reinstall it, as that will correctly fill all the needed metadata (including the updateUrl).

Why is this useful? It's good for when one single user uses multiple computers. So this user can publish the style from computer A, later start using computer B and publish an update, and then go back to computer A to fetch the update.

How to reproduce

  1. Write a new User CSS.
  2. Click on the Publish button to publish to USW.
  3. Publish as a new style.
  4. After publishing, observe how the style in Stylus is now linked to the published version.
  5. Go back to the list of installed styles.

BUG: There is no icon/button to check for updates for this just-published style, hence it's never checked for updates.

Screenshots

When I publish a style, it gets linked to USW. But, as you can see, there is no option to update the style that has just been published:

List of installed styles

The information under their "Publish" section looks exactly the same.

Publish section Publish section

But if you open the (normally hidden) "Settings" dialog for each style, one of them doesn't have the updateUrl.

Settings Settings

System Information

Additional Context

I can see the install-usercss/install-usercss.js file sets up updateUrl (and possibly other kinds of metadata that I haven't looked), while the edit/usw-integration.js doesn't.

The expected behavior is to automatically set the newly-generated USW updateUrl, unless the style source-code explicitly sets @updateURL.

denilsonsa commented 1 year ago

Bonus issue: since the updateUrl is not set, when opening the USQ page for the published style, the button says "Install" instead of "Reinstall". If you click on "Install", the confirmation page (generated by this extension) correctly says "Reinstall".

tophf commented 1 year ago

The arguments you provided didn't convince me that a purely outgoing operation should set an incoming-type relation.

denilsonsa commented 1 year ago

Well, one more reason is that the updateUrl does not exist before-hand, and it is only created after publishing. So, should this new URL be automatically saved for the convenience of the user? Or should it be completely discarded like it is right now?

Additionally, the user is publishing to a place where only the user has write access. Thus, any changes will happen due to the user's own actions, and thus the user may expect to have those changes synced across multiple devices. And publishing the styles is the easiest way to save/sync styles.

Like I said, the current behavior is inconvenient for any user that either has multiple devices (desktop computer, laptop computer, work computer, possibly a mobile device that could potentially support extensions) and/or multiple browsers or multiple browser profiles.

tophf commented 1 year ago

I'm still not convinced, the idea still sounds very very very wrong conceptually. What's so complicated about installing the style manually?

denilsonsa commented 1 year ago

What's so complicated about installing the style manually?

I'm already doing the workaround of "Publish → Open USW page → Install → Reinstall → Close those tabs". It's not an intuitive workaround, though. Let me try to explain:

After using Stylus for several months (maybe years) without publishing anything, I developed a mental model of how user-styles work. They can either be "local", completely disconnected from anywhere else (if I created them locally); or they can be "connected", which means they have an upstream URL and thus they get in sync with upstream as much as possible (if I installed them from some website).

Then, at some point I discovered I could publish/update remote styles directly from within the Stylus extension itself. That's extremely convenient and useful. That's when I started publishing my newer local-only styles to USW. My expectation was that those styles would become "connected" after being published. That's also in-line with how adding a git remote repository works: after a local-only repository gains a remote repository, it is now possible to push and pull changes.

Which leads to this "bug". After publishing, those styles end-up in a half-connected state: I can push more changes, but I can't pull newer changes I made in another computer/browser/profile. That feels broken. Also because the workaround is to just reinstall the styles, which means things will get initialized properly.

And that's inconvenient because when I press "Check all styles for updates", if doesn't check these half-connected styles, leading to frustration and troubleshooting as to why they are not up-to-date, culminating in just reinstalling those styles to fix them.

Sidenote: I'm no stranger to user styles. I wrote many local-only *.user.css styles that were natively supported in Opera browser (back in the Presto engine). Later, I used Stylish and also wrote and published many styles. Fast-forward to now, and I'm using Stylus and I've imported all the old styles into USW.

Then, I can ask the question back to you: What's so wrong about letting published styles to be synced two-way?

Adding the updateUrl will allow these styles to be checked for updates. If any local change happens, Stylus naturally warns and asks for confirmation before overwriting with the new version. (Well, at least that's the behavior with any third-party style.) Thus, there is no risk of accidentally losing local changes.

In fact, not having the most up-to-date version can lead to diverging code, as the user modifies an older version of the style because that style wasn't synced. And that can lead to waste of time and loss of changes.

The arguments you provided didn't convince me that a purely outgoing operation should set an incoming-type relation.

Publishing a style for the first time isn't just a pure outgoing operation. It's, in fact, two operations together: "connect this locally-installed style to this remote style", followed by the pure-outgoing "publish the changes over there".

tophf commented 1 year ago

I don't see it this way. To me publishing is not git, it's a purely outgoing operation, and it should remain so. Theoretically we could add an option in the publishing panel, but it doesn't make any sense to me conceptually, moreover installing the style explicitly is a trivial operation that one can perform in a matter of seconds if necessary.