Introduction to the uWolf thread.

This thread is dedicated to discussing the uWolf LibreWolf wrapper, where you can ask questions, help with development, and receive updates on the project.

Due to many bugs LANDSCAPE is officially unsupported.

Useful Links

• The uWolf project is hosted on GitHub and can be found here.
• The latest stable release is available on Open Store.
  

Development Log (DEVLOG)

Release: v0.7.21

STATUS: Released on Openstore

• Fixed FP4 Scaling Issues: The scaling issue was resolved by capping the maximum scaling at 2.4 and the minimum at 0.7.
• Fixed Tab Bar Issues in Landscape Mode: The tab bar was rewritten to dynamically adjust margins based on screen percentage instead of using fixed values.

Release: v0.7.18

STATUS: Released on GitHub

• Librewolf version update: now v140.0.2-1,
  note: updating to this version seems to fix addon button killing OSK.

Release: v0.7.17

STATUS: Released on Openstore

• OSK Overlay Improvement: Enhanced OSK overlay height calculations to reduce overshoot, resulting in a more accurate and user-friendly experience.

Release: v0.7.16

STATUS: Released on GitHub

• XUI Improvement: Simplified UI changes have been implemented, significantly enhancing the overall XUI experience. Although settings cannot be accessed while in landscape mode, this change mitigates previous issues. Additionally, addon management is now available, and the bookmark button (star) has been reinstated.
• Location Feature: A location policy has been added, providing uWolf with access to location services.

Release: v0.7.15

STATUS: Released on Openstore

• Search Engine Fix: actual solution implemented as suggested by MrOtherGuy here for the Issue here, no more database Injection.
• Librewolf version update: now v139.0.4-1

due to little change in overall architecture no flowchart is provided, for up to date flowcharts visit the github repository.

Release: v0.7.14

STATUS: Released on GitHub

• Simplified OSK Hide Mechanism: This release patches osk_config_trigger.uc.js to improve the responsiveness of hiding the OSK overlay while browsing, making it feel less bloated. The change came from shifting focus to the end-user experience and identifying what triggers the OSK to hide.

Release: v0.7.13

STATUS: Released on GitHub

• Search Engine Fix: Alternative Solution: Although the underlying issue persists, I've implemented a workaround by injecting a pre-populated database containing search engine data. This approach circumvents the need for manual configuration, effectively masking the problem. It's essential to note that this is not a bug on my end, but rather a compatibility issue between LibreWolf and fx-autoconfig. I've opened an issue here for those interested in resolving the root cause.
• Enhanced OSK Hide Mechanism: The On-Screen Keyboard (OSK) hide mechanism has been refined to dynamically respond to URL changes. For instance, when searching on a search engine, the OSK overlay will now automatically hide, eliminating the previous awkward behavior that required manual intervention.

For those interested in the technical details of the database injection and to address the security concerns raised by @domubpkm, I've included a flowchart that illustrates the management of the LibreWolf profile. This should provide a clear understanding of the process and help alleviate any concerns.

Release: v0.7.11

STATUS: Released on github
Significant updates have been made in the release:

• OSK Dynamic Reactions: The browser detection mechanisms have been replaced with a more robust approach, utilizing a Dbus monitor to listen for OSK focus events. However, this new method has a limitation: the Dbus monitor can only detect when the OSK gains focus, but not when it loses focus. This introduced a challenge in detecting unfocus events, which has been temporarily addressed by implementing a crude solution involving a tinted overlay over the screen. This overlay is active when the OSK overlay is shown, allowing the system to detect when to unfocus.
• Bug Fix: The is_tablet function, which resulted in many crashes in the v0.6.10, has been fixed.

For those interested in a more detailed understanding of the new OSK dynamic reactions architecture, a flow chart is provided.

---

If you have any questions or would like to discuss the development of uWolf, please don't hesitate to ask in this thread. Your input and feedback are valuable to the project. Feel free to share your thoughts, suggestions, or concerns, and I'll do my best to address them.

@Fuseteam first let me say this is awesome, second if you want help I want to contribute to this.
I used nixos for while before switching to FreeBSD is has been a joy, so I say this with confidence this is finally the point where we can actually use UT as a full on linux distribution, the influx of packages here will be amazing.

if you don't mind aside from reading up on the code, I will make a UI QML app so end users can just pick and install/uninstall primitive but any UI is better then terminal when walking.

looking forward to seeing a repo on gitlab.

@domubpkm the next step is to wait for Noble, i have somethings i can fix right now
bit i rather just do one big bug sweep session when switching to wayland.

as soon as the transition to noble happens i can automatically make the phone install the subsurface patch (until it goes to upstream) and then i can run wayland which means a host of bugs will be gone but i already know some stuff breaks (and my workarounds for the xwayland bugs) so i will probably need to do a refactor of the entire app so i might as well do everything in one big concentrated push.

edit:
other then that?, really only cleaning up the UI mostly.
i can't really do anything else, though i am toying with the idea of making another startup script to mimic webapp-container so webapps can use this (they'll need to be unconfined)
also finding a way to make uWolf the default browser, after the switch to wayland it should be a lot more usable so it stands to reason people will want to be able to make it open links.

@domubpkm There is a security issue, but it's relatively minor and manageable. The problem lies in JavaScript files with privileged execution that can access browser internals and read files on the host. However, the risk is mitigated by the fact that:

• Librewolf stores sessions in cache, so malicious code would only execute in the next session (after restart)
• The sensitive files are re-read and replaced every time a session is launched, making it difficult for changes to persist
• The time window for tampering with the files is small (between verification of the Chrome folder and Librewolf launch)

To further reduce the risk, encryption and obfuscation of the sensitive files could be implemented, but this would make it harder for me (the developer) to test and debug code. The issue will be addressed once the more significant problems are resolved.

It's worth noting that Librewolf is considered a secure browser, and the privileged code execution is heavily sandboxed, preventing access to web content among other things. While this issue could potentially be exploited to steal data, the overall security of the browser is still robust, and any other security problems would likely originate from the Librewolf/Firefox source code itself.

@Fuseteam and I are working on making this a plugin, I just finished writing the automation/management of nix or at least the early version of it.

can find it here.

@Lakotaubp Done! https://forums.ubports.com/topic/11060/uwolf-librewolf

@johndoe we are working on a plugin to lomiri system settings like Libertine plugin.

I already have most things implemented in backend, mostly lack some generation control over nix/home-manager left other then that mainly implementing the main UI, I have a design ready just need to implement it.

@domubpkm I'm currently going to do a massive rewrite of UI, this will fully adopt UI to mobile by extensive use of javascript this will also be unstable and take at least a week to do and another to get stable.

@haagch thanks, I will make room for bookmark button and extension button.
i was doing this today.

@domubpkm
I'd estimate the total time spent to be around 110-120 hours.

Here's a breakdown of how it was spent:

• The first 5 hours were completed a couple of months ago building version 0.1.0, which involved creating a setup script for running LibreWolf with no modifications, @Fuseteam helped a lot with this considering his experience with uFirefox.
• The remaining work was done over the course of 2.5 weeks, with daily work sessions averaging around 7 hours, and some days going up to 12 hours.
• To avoid burnout, I took a few days off, roughly every 3 days, which helped to maintain productivity.
• It's worth noting that a significant amount of time was spent exploring and testing different ideas, many of which were eventually scrapped, which made the work more time-consuming, especially in the beginning.