Environment:
- Orion: Version 1.1.2 (151) on macOS
- Extension: HoverRoute 1.1.3, installed from the Chrome Web Store
A download rule is configured as:
Images/X/${date}/${filename}
Steps to reproduce:
- Create a new clean Orion profile.
- Install HoverRoute 1.1.3 and enable third-party extensions.
- Create and enable a rule matching x.com or twitter.com with the path above.
- Open an image on X.
- Click the HoverRoute download button.
- Check the default Downloads folder.
The download succeeds, but Orion removes the "/" separators and saves the file
directly in Downloads. For example:
Expected path:
~/Downloads/Images/X/2026-07-19/example.png
Actual path:
~/Downloads/ImagesX2026-07-19example.png
No subdirectories are created.
The same extension and rule work correctly in Chromium-based browsers and Firefox.
Safari comparison:
This is not directly testable in Safari because HoverRoute is distributed
as a Chrome/Firefox WebExtension and is not installed from the Chrome Web
Store in Safari. Therefore I cannot confirm whether this is a generic WebKit
issue. The behavior appears specific to Orion's WebExtension download-path
handling.
The filename supplied to browser.downloads.download() should be interpreted
as a path relative to Orion's default Downloads directory.
Orion should preserve the "/" separators, create the required subdirectories,
and save the file as:
~/Downloads/Images/X/2026-07-19/example.png
This behavior is consistent with Chromium and Firefox. Orion's WebExtensions
support table also lists downloads.download and download.filename as fully
supported:
https://orionbrowser.com/WebExtensions-API-Support.html
API reference:
https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/downloads/download
Version 1.1.2 (151)
Tahoe (26)
