Start up browser and go to the settings, check if you have “Behavior” section at the bottom, if not, reboot the phone.
after reboot check again if you have the option,
play with the browser until it crash
once browser reload, go to settings, observe the “Behavior” section is gone even that browser.qml and SettingsPage.qml of the browser still contains the patch.
go to terminal, kill /usr/libexec/mapplauncherd/booster-browser --application=sailfish-browser
start up browser, go to settings, observe the “Behavior” section is back again
EXPECTED RESULT:
After browser reload the patch should still be there, the Behavior section shouldn’t be gone
ACTUAL RESULT:
Even that browser qml files still contain the patch, the Behavior section is gone.
odd, with 4.4.0.72 I didn’t spot this. Anyway I wonder what’s the problem. The files has the modifications, so how come suddenly the same binary reading from the same files “doesn’t see them”?
I think the booster has somehow cached original qml, had similar weird behaviour when playing with the dialler app and my changes would half of the time not be reflected in the app when launched from launcher, see if it consistently shows up when starting from cli
it’s enough to kill booster and start app from the menu. So yeah it’s definitively booster, I mentioned this in the bug. The question is how can I clear booster cache?
I don’t think so. I checked the browser files as mentioned in the bug report and my changes are still there.
Or you think that somehow patchmanager suddenly disable and enable the patch again?
We could include the equivalent for the browser-booster user service if you can confirm that this is the case when the patches do not work: the browser-booster starts before patchmanager.
With something like journalctl -b | grep -E booster\|patchmanage you can see if the services started in which order (or you could install systemd-analyze --user)
Ok I’ll try to debug the logs and get back to you with some information.
For now I’m trying to understand.
So you’re trying to say that all the patches managed by patchmanager are applied every time on system reboot?
That would be really odd and then your solution with order of service starting would made sense. However, if the “patch is forgotten”, it’s enough to reboot. I.e. it always works after reboot. So that’s probably something else, but of course I’ll dig in the logs and try to find something there!
Oh, so it always works correctly after reboot, but doesn’t work after a browser crash. That may be different indeed.
For your other question: patchmanager uses a preload lib to redirect patched files to their patched version. The way that works is by the preloaded library talking to the patchmanager service.
I assume there will be logs when the browser crashes, if you run devel-su journalctl -f when that happens - ideally from a computer - and then start the browser, you may have bug-worthy material…
ok this is something I’m trying hard to understand. I think it’s because of this part:
lib to redirect patched files to their patched version
Could you please drop a bit more light onto this?
In the mean time it seems crash is not the only activator of this behavior. I closed browser, locked phone, then after some time unlocked it, started browser and boom, browser doesn’t “see patch”. I was on the go I didn’t want to check if the patch is still in the .qml files but I have no reason to believe it’s not there. Of course killing booster-browser fix the problem.
ok thank you, but I can’t find the connection between this and qml files. Right now my patch is just a simple diff against qml file which is applied by patch -p1 < unified_diff.patch. So, where’s redirect you’re mention in this involved? I’m unable to put this pieces together. It’s clear for so, hence the LD_PRELOAD etc but for diffs against qml?
I assumed this was done through patchmanager, which, for the qml files, will look them up by this preload + overloading open + asking a service for the actual file to respond with.
If you are patching directly the filesystem and the crash or browser close still malfunctions I am out of words how that can happen (assuming patchmanager has bugs was doable, otherwise I don’t understand either).
(Remember, patchmanager doesn’t actually patch the files, but makes copies of them + redirects them there through the LD_PRELOAD mechanism).
So maybe it’s time you share some more details how you reproduce this, through patchmanager or by changing the filesystem with patch command?
Sorry, maybe this was not explained. You generate a patch as an unified diff, but patchmanager doesn’t just patch it in place, but goes through that LD_PRELOAD redirection.