Does not always scale at startup

[gearhead]

Current Behavior:
Intermittent problem. Sometimes when luakit is launched, it does not appear to read the scaling setting. Restarting the browser will cause it to read and scale appropriately. It may be related to the fact that weston is started by the service file before luakit (After and Wants in the systemd service file). If I start weston and ensure it is runing and 'up'. luakit appears to scale appropriately at start, but I am not 100% convinced of this as the scaling issue is intermittent. I cannot figure a set of constraints to make it happen every time.

Desired Behavior:
Scale appropriately each launch.

How can we reproduce it (step by step):
I use a scaling less than 100%. This does not happen every time and if started once and the scale is 100% and restarted, it scales appropriately, I have tried adding a delay after weston starts in the service file, but this did not seem to make any change in behavior. Most regularly, but not always, if I reboot the RPi it will display at 100% scale the first time but when restarted it will scale appropriately as in the userconf file.

Environment:
RPi 3B+ under Weston
Linux Distribution & Version:
Arch Arm AArch64 Kernel 5.10.27
Output of luakit --version:

luakit 2.3
  built with webkit 2.30.6 (installed version: 2.32.0)

.config/luakit/userconf.lua

local settings = require "settings"
settings.webview.zoom_level = 55
settings.window.home_page = "localhost"

I launch it with a service file local-browser-w.service:

[Unit]
Description=launch Local Browser Kiosk mode
After=network.target weston.service
Wants=weston.service

[Service]
Type=simple
User=http
Group=http
WorkingDirectory=/srv/http
Environment="HOME=/srv/http"
Environment="XDG_RUNTIME_DIR=/run/weston"
Environment="WAYLAND_DISPLAY=wayland-0"
Environment="XDG_SESSION_TYPE=wayland"
Environment="GDK_BACKEND=wayland"
ExecStartPre=/bin/sleep 3
ExecStart=/usr/bin/luakit
ExecStop=/usr/bin/pkill -15 luakit
ExecStopPost=sudo /usr/bin/pkill -15 weston
TimeoutSec=infinity

[Install]
WantedBy=multi-user.target

Note about webkit issues:

If you're reporting a rendering issue, please test it with the gnome
browser ephiphany as well. If the issue occurs there too, we're very
likely not able to help. These issues should be reported to webkit:
https://bugs.webkit.org

[taobert]

Well i'm out of my depth on both Wayland and systemd.
Looking at your code, i would assume you want more Afters.
It woulld be good to confirm that you don't see the intermittent failures when it's not started from a service.
Does adding heaps of time to ExecStartPre=/bin/sleep 3 change the behaviour?
What about explicitly starting, killing and restarting?
Can Wayland start programs when it's up and running (akin to .xsession)?

I would have guessed that luakit would be WantedBy=graphical.target rather than multi-user.target.
It also appears that you can make your own targets, and perhaps contriving to start luakit After graphical.target is complete is required.
Edit: Although i haven't read it in detail, this might give you some more ideas.

[gearhead]

The really strange thing is that it does scale properly much of the time. Today, I've launched luakit numerous times and it always scaled properly. Last week, it was a bit more variable. This is the strange thing and why I suspected a delay would help.

I finally was able to read through the link you sent. I may have gotten the gist of it, but I think what I am doing is a bit different to sway-wayland. To answer your questions:
This is never launched automatically as an 'enabled' service. This is running on an RPi which is normally headless. Some users have added screens to their RPis and they want to use it as a 'kiosk' to display the local web page. We've previously run xorg/chromium and have switched to xorg/luakit and I am trying to see if we can use weston instead of xorg.

Luakit is launched via our php UI from a remote browser or frmo a running service after everything else is up. There are no 'login' users other than root. That is why we are using user 'http' for both weston and luakit. We may want to adjust from this but it is how we are running xorg and we are duplicating it for weston. When we call the luakit.service file, weston is not up, or should not be, and the intent is that the 'After=weston.service' just commands systemd to start weston first before it tries to start luakit. Otherwise there is nowhere to display it.

I have tried playing with the sleep times and it does not seem to have any effect I added the 'sleep 1s' and it started working then I deleted it and it worked then failed again. It does not do it all the time. The simple systemd service I wrote to launch weston when this luakit service is called is attached in case that may be helpful. My weston.service is a bit screwy as weston is designed to be launched as by a (logged in) user. Since we don't have one except root, I had to set it up this way. I have to first launch weston then chown its PID and pipe to http:http so that luakit can also be launched and run as http in weston and displayed on the local screen. Maybe a bit convoluted, but it was how I was able to make it work. Any suggestions appreciated.
weston.service

[Unit]
Description=Weston Kiosk mode
After=network.target

[Service]
Type=notify
Group=http
RuntimeDirectory=weston
RuntimeDirectoryMode=0700
Environment="XDG_RUNTIME_DIR=/run/weston"
ExecStart=/usr/bin/weston --tty=1 --log=/var/log/weston.log --config=/srv/http/.config/weston.ini --modules=systemd-notify.so
ExecStartPost=/usr/bin/chown -R http:http /run/weston/
ExecStop=/usr/bin/pkill -15 weston
IgnoreSIGPIPE=no
StandardOutput=journal
StandardError=journal
TimeoutSec=infinity

[Install]
WantedBy=multi-user.target

[mburakov]

Hi all, I have a similar (same?) issue.

The difference is that I use Arch on x86, and start luakit as a regular desktop app.
These are all the settings I change:

local settings = require('settings')
settings.session.always_save = true
settings.webview.enable_accelerated_2d_canvas = true
settings.webview.zoom_level = 120
settings.window.default_search_engine = 'duckduckgo'

Often I see that zoom level is just not applied when opening a new page. It does not seem to matter if I open a website in a new tab or in the same tab. Even if I open the same site in the same tab, zoom level is still reset to 100. At the same time it always properly applied after I reload the page.

Upd: the default zoom setting is also often not respected when following links (that is, there seems to be no difference vs opening a page via :o).

It can be really weird, i.e.:

1. Open a web-site
2. Observe 100 zoom
3. Reload the page (r)
4. Zoom changes to 120
5. Open the same web-site in the same tab (:o)
6. Observe 100 zoom
7. Reload the page (r)
8. Zoom changes to 120

Environment:
x86 under Sway WM
Linux Distribution & Version:
Arch x86_64 Kernel 5.13.4-zen
Output of luakit --version:

luakit 2.3
  built with webkit 2.30.6 (installed version: 2.32.3)

[mburakov]

One more observation on my setup, that might be useful. When following a link (and the issue reproduces), the previous page is updated one last time with zoom level 100. This happens immediately before opening a new page.

[gearhead]

I still get this on occasion. Usually a restart of luakit fixes it. It is strange that it does not seem to read the config at startup every time or if it does, it just ignores the scaling but not anything else. It always goes to the settings.window.home_page = ''localhost" but sometimes ignores settings.webview.zoom_level = 55.

[taobert]

Well, I can't make this manifest under X, so i'm very much spitballing.

(I believe that) there can be a race condition with settings in tab creation (which may cause #965).
However, @mburakov's assertion that they see this even when navigating in an existing tab, suggests that this is not the case here.
Nevertheless, could you try this patch?:

diff --git a/lib/webview.lua b/lib/webview.lua
index 188c3a3a..3f6544aa 100644
--- a/lib/webview.lua
+++ b/lib/webview.lua
@@ -744,6 +744,8 @@ _M.add_signal("init", function (view)
         elseif status == "provisional" or status == "redirected" then
             local val, match = settings.get_setting_for_view(v, "webview.user_agent")
             set(v, "webview.user_agent", val, match)
+            local val, match = settings.get_setting_for_view(v, "webview.zoom_level")
+            set(v, "webview.zoom_level", val, match)
         elseif status == "committed" then set_all(v) end
     end)
     view:add_signal("web-extension-loaded", function (v)

Even if this patch alleviates the problem, it may bot be the best solution.
I've noticed that :set webview.zoom_level 55 doesn't update the page immediately, but requires a reload.
So if the problem is that the setting isn't acknowledged yet when the page renders,
the solution may not to be to make it acknowledged earlier, it may be to redraw the page whenever it does get acknowledged.

[gearhead]

I will try this patch. I still see this under X11 and Weston. It is not all the time. But I saw it 2x yesterday and probably 4x it started fine. I've never seen it re-scale, but I never wait for it. If it comes up full scale (100), I cannot access all the screen picks, so I have to restart it.

[gearhead]

Just built and tried it. It does not appear that this patch causes luakit to do anything differently. I still get the 100% scaling periodically even though I have the scale set to 50. If it does start at 100, if I shut it down and restart it, it usually fixes itself.

[taobert]

OK. Thanks for trying. It was a bit of a long shot.
This is a bit of a brain-dump, so my apologies if some of it doesn't hang together well.
I'm happy to clarify things if you'd like me to.

I had been under the impression that this only happened under Weston,
(and indeed i am unable to make it happen on my X11 amd64 machine,)
but it seems that i can make it happen on a headless rpi displaying to X11/amd64 over ssh,
so it'll be easier now for me to prod at it, time permitting.

As an aside, i'm pretty sure it was not happening on the rpi until i upgraded a bunch of things (Raspbian Stretch -> Debian Sid) so that i could build the current develop branch, so this may be bisectable, and may be not-our-bug.
I'd have to reinstall and retrace my steps to confirm that.

Complicating things slightly for me are presumably unrelated and idiosyncratic dysfunctions on my rpi install,
in particular, i can't get to the settings page (and others) due to the error:

libEGL warning: DRI2: failed to authenticate

(WebKitWebProcess:2292): Gdk-ERROR **: 08:58:06.491: The program 'WebKitWebProcess' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadRequest (invalid request code or no such operation)'.
  (Details: serial 199 error_code 1 request_code 155 (unknown) minor_code 1)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the GDK_SYNCHRONIZE environment
   variable to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)

https://google.com and https://en.wikipedia.org load fine and allow me to test the zoom_level.

Based on the play i've had, I see the following:
Using settings.webview.zoom_level = 55 in userconf.lua causes the zoom_level row on the :settings page to be greyed out and unchangable (on amd64) and for :set webview.zoom_level ... to have no effect. This may be a bug.
If userconf.lua instead contains settings.set_setting( "webview.zoom_level", 55), then the setting is changable in-app, both via :settings and :set ..., however this requires a page reload to effect the change.
If i explicitly set the zoom on the webview with :lua w.view.zoom_level=0.75 it takes effect automatically (this can take a few seconds on rpi), but on reload reverts to whatever it was previously.

When this issue doesn't manifest, setting the zoom_level with :set webview.zoom_level 75 and reloading behaves correctly.
When it does manifest, using :set webview.zoom_level 75 and reloading changes nothing. Assigning to w.view.zoom_level behaves as above.

When i see this issue manifest, :lua print(settings.webview.zoom_level) prints "55" to the console,
whereas :lua print(w.view.zoom_level) prints "1" (rather than "0.55").
So it would seem that the settings are read from the file, but are perhaps not applied to the webview.

Creating new tabs seems to maintain whichever state (zoom_level correct or incorrect) luakit started in.
So the dysfunction (or at least its trigger) would seem to be upstream of webview/WebKitWebProcess creation.

Contrary to the original post, i have seen this is issue manifest on two successive startups.

My observations that neither loading new tabs nor navigating/reloading within a tab
change whether the zoom_level is correctly applied are strikingly different from @mburakov's.
So i wonder whether there may be different issues on rpi vs x86.
@gearhead can you replicate/confirm my observations above, so that i know i'm looking at the same thing you are?

Issues #469 and #357 may be pertinent.

[gearhead]

I'll need some hand holding to actually check these things as I do not know how or where you are going to check them.

My screen is a 3.5" spi connected screen. I can add a mouse and a keyboard if needed to troubleshoot, but will need pretty specific instructions.

[taobert]

Ok..

With the keyboard connected, you should also be able to test loading new tabs (T) and windows (W), and reloading the page (R), and confirm that none of these change the effect of the zoom_level.
You should also be able to enter Command mode by pressing :.
One of the standard commands :lua allows you to enter lua expressions to be evaluated.
I find this useful for investigating what's set where.
For me, the lua print function writes its output to the terminal that i started luakit from.
I gather you're starting luakit on the rpi as part of systemd's boot process, and wonder whether there's a log of luakit's stdout somewhere. If not, you can instead use w:notify() to print to luakit's status bar instead of stdout.
In this case the prints above might get rewritten along the lines of: :lua w:notify("w.view.zoom_level: "..w.view.zoom_level).

If it's more convenient, you may be able to ssh to the rpi from a keyboard and X11 (or maybe Weston) enabled machine and launch luakit from the command line, which is what i'm doing.

[gearhead]

I had a few minutes today and can confirm that when it starts at a the zoom level from the userconf.lua that the 'zoom_level' is greyed out. When I change the zoom by :lua w.view.zoom_level=0.75 it does change and is immediate. Pretty quick on my 3B+. I will have to get it to come up at full scale and try a few things but that may have to wait for the weekend.

[gearhead]

I just got it to start at 100%. From this state, when I type :lua w.view.zoom_level=0.50 it immediately re-scales to 50%. Now every time I restart it, it starts at 50% (and the arrow cursor is back)... OK I finally got it to start at 100%. I get the same thing you do:
:lua print(settings.webview.zoom_level) prints "55" to the console,
whereas :lua print(w.view.zoom_level) prints "1" (rather than "0.55").
When I try to set webview, :lua w.view.zoom_level=0.5 it immediately scales and when I type :lua print(w.view.zoom_level), it reports 0.5 on the cli. So, What I see when it does not scale at startup is identical to what you are seeing.