Many thinks for the improvements!

Thanks, I've tried those two themes and maybe understood what you told about. In short, you need to clear --browser-bg-images with the custom user style, like following:

#background {
  --browser-background: rgb(12, 12, 13);
  --browser-bg-images: none;
}

Background images are always rendered over the background color. From TST 3.8.2 style declarations for the background is separated to each property: background-color, background-image, background-position, background-size and background-repeat. The variable --browser-background affects only to background-image.

I think this is a problem of user style rules wrote for old versions TST. In general, user styles always need to be updated when TST is updated. This is the reason why the user styles editor is placed under the "Advanced" section: it is a feature for people who know CSS and how to inspect TST's sidebar itself. If you find something CSS snippet incompatible to the latest TST, the wiki page need to be updated.

This now passes two GNU testsuite Tests that fail on master branch.

============================================================================
Testsuite summary for GNU coreutils 8.32
============================================================================
PASS: tests/id/uid.sh
PASS: tests/id/zero.sh

However, some of the tests I wrote behave differently in the CI environment and need further debugging.

I think it is impossible to cleanup needless migratedBookmarkUrls values, because TST cannot detect which case was happeed about an updated migratedBookmarkUrls: "synced from other devices" or "imported from a file".

From Firefox 63, Gecko eventually (will) ships Shadow DOM and Custom Element as known as Web Components.

These features provides a way to create a custom DOM element and encapsulate it. I think they would useful to building a view for this add-on.

To be honest I still cannot understand what is the better future produced by completed migration to WebComponents. I think that the WebComponents technology is designed for modules shared across multiple projects, like confirmation dialogs ( https://github.com/piroor/webextensions-lib-rich-confirm ). It looks reasonable that style definitions in TST does not affect to such shared components accidentally, on the other hand, such isolation still looks overkill for me, to implement components available only in this project.

But I possibly misunderstand the power of WebComponents. If Firefox's native tabs are reconstructed with WebComponents, I'll learn effective usage of the technology to implement project specific components. I close this until the time.

I'm using Firefox 89 on OpenSUSE Tumbleweed. TST version: 3.8.1.

I followed "How to apply GTK+ theme color on Linux?" on Readme. It seems the fix for GTK theming doesn't work so well with the Proton UI when using "system theme". Here is an example:

I think the unused tabs should not have "frames" and should blend in the background. This is the design principles of the Proton UI.

Interestingly, when I followed "How to apply colors customized via Firefox Color?" on Readme. Theming works better with Proton UI:

I was using dark theme of Firefox. As you can see, unused tabs blend in the background.

The new commit made the Proton theme works even better than the GTK hack before. The TST background colour now exactly matches the background colour of the tab bar.

I've tried to reset all configs and reload TST, then TST just notifies a message for new users. The problem wrongly notified "sync available" message should go away, except imported configs contains sync information.

The sync feature is sadly very incompatible with import/export configs between synchronized devices. If you export all configs from a synced device and import it to another synced device, "device id" information will be wrongly duplicated and TST cannot detect such a duplication. Thus something warning message looks to be required around import/export. (But I think I should not ignore some keys on import/export even if they are dangerous, because the feature can be used for backup.)

@piroor commented on 2021. jún. 13. 11:25 CEST:

Please describe how to reproduce the problem you saw on my environment. I don't know what theme you are using.

I'm not sure there's a problem, or that I just don't understand what happens and why. The background being replaced despite being set by --browser-background: rgb(12, 12, 13); in TST happens even with the FF built in alpenglow theme. I guess this could be a potential bug. (Otherwise I wouldn't even noticed that this is possible)

The bitmaps being scaled I guess are normal, since what the themes use are nowhere near as tall as the sidebar. These are some that I tried, where it's noticeable: https://addons.mozilla.org/hu/firefox/addon/rustic-wood/ https://addons.mozilla.org/hu/firefox/addon/dark-wood/

Awesome, thanks! Could you add a test for the case where no argument is given?

Please describe how to reproduce the problem you saw on my environment. I don't know what theme you are using.

I am by no way an expert when it comes to file system permissions, but I think if you own the file you can do anything with it... Otherwise you could create a file that can no longer be deleted if you change permissions. According to GNU's codumentation:

When setting file timestamps to the current time, touch can change the timestamps for files that the user does not own but has write permission for. Otherwise, the user must own the files.

Sorry I missed the last note about disabled Proton.

"context-fill" for icons is availble only on Firefox 62 and later, and doesn't work on ESR60. After ESR60 is outdated and new ESR (66 or 67?) is released, we need to switch icons to context-fill versions.

Thanks I forgot about this.

Interesting discovery (at least for me): I created a file, gave if 0444 then tried to touch it and expected it to fail. It doesn't... It works like a charm. Then I thought "Of course it works, cause touch just opens the file and the OS actually changes the access time. So as long as you have read access, touch will work". Then I checked the options touch has and noticed a --date that allows you to set a specific access time. Then I thought "Ok, so in this case, touch manually changes the access time instead of relying on the OS. So for sure this will fail for a read only file". It doesn't... So then I went ahead and chmod 0000 the file and tried touch again. Works just fine. So now I'm confused about how touch works grin

There's a difference between meta data and the file itself. See also

@piroor commented on 2021. jún. 13. 11:06 CEST:

I've reconstructed the Proton theme totally after TST 3.8.2. Could you try the latest development build https://github.com/piroor/treestyletab#development-builds ?

Is anything supposed to look different? It looks rather identical to me.

@floriangasc I couldn't reproduce such a crash on my testing archlinux environment. Something stored information may trigger the problem. Could you try bisection to minimize conditions to reproduce the problem? How to do that: https://github.com/piroor/treestyletab/wiki/How-to-minimize-conditions-to-reproduce-a-problem

@piroor commented on 2021. jún. 13. 11:06 CEST:

I've reconstructed the Proton theme totally after TST 3.8.2. Could you try the latest development build https://github.com/piroor/treestyletab#development-builds ?

I guess. But right now I don't have proton enabled. So, regardless of proton something changed on FF side to make this possible?

I've reconstructed the Proton theme totally after TST 3.8.2. Could you try the latest development build https://github.com/piroor/treestyletab#development-builds ?

Interesting discovery (at least for me): I created a file, gave if 0444 then tried to touch it and expected it to fail. It doesn't... It works like a charm. Then I thought "Of course it works, cause touch just opens the file and the OS actually changes the access time. So as long as you have read access, touch will work". Then I checked the options touch has and noticed a --date that allows you to set a specific access time. Then I thought "Ok, so in this case, touch manually changes the access time instead of relying on the OS. So for sure this will fail for a read only file". It doesn't... So then I went ahead and chmod 0000 the file and tried touch again. Works just fine. So now I'm confused about how touch works 😁

I know how I can test the permission denied thought. I need to create a directory and restrict permissions on the directory not the file. Then touch will not be able to reach the file and throw a "Permission denied" error.

Short description

I had a theme installed which adds a background image to the toolbar After updating this vertically stretched became the background of TST. Which doesn't look that hot with the scaled image.

Also, the weird thing is I'm quite sure I overrode the background of TST: --browser-background: rgb(12, 12, 13);

Not sure what to make of this, previously I couldn't make the background the same as the toolbar via CSS, even though I tried. And even now it doesn't work for the built in white theme, but does with Alpenglow.

So what does this mean. Now it's possible to match the appearance of TST with the browser UI? But only via theme? Or CSS as well? Only via image background?

Is the background being overwritten even though me having set a background color a feature or a bug?

By the way: I have disabled all proton options via about:config.

Environment

• Platform (OS): Win10
• Version of Firefox: 88.0b9 (dev edition)
• Version (or revision) of Tree Style Tab: 3.8.2

The change looks to solve the problem on regular dialogs.

There also seems to be a delay in the regular dialog, though not after closing, but between the click and the closing.

I couldn't reproduce this on Firefox 89.0 on my macOS 11.4 Big Sur. Hmm...

Could you try the latest development build? https://github.com/piroor/treestyletab#development-builds