List items
Items from the current list are shown below.
Gecko
22 Jan 2024 : Day 146 #
I'm still in the process of fixing the Sec-Fetch-* headers. The data I collected yesterday resulted in a few conclusions:
I do note however also notice that DuckDuckGo doesn't load correctly for these cases, so presumably there's still a problem with the headers here. I'll have to come back to that.
The inability to use the Back or Forwards buttons is also beginning to cause me trouble in day-to-day use, so now might be the time to fix that as well. Once I have I can test the remaining cases.
My suspicion is that the reason they don't work is related to this error that appears periodically when using the browser:
A different possibility is that this, at the top of the SessionStoreFunctions.jsm file, is causing the problem:
A quick search inside the omni archive suggests this file is indeed missing:
But it's late now, so I'm going to have to figure that out tomorrow.
If you'd like to read any of my other gecko diary entries, they're all available on my Gecko-dev Diary page.
- Opening a URL at the command line with a tab that was already open gives odd results.
- Opening a URL as a homepage gives odd results.
- The Back and Forwards buttons are broken so couldn't be tested.
- I didn't get time to test the JavaScript case.
- Open a URL using JavaScript simulating an HREF selection.
- Open a URL using a JavaScript redirect.
<!DOCTYPE html>
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<meta name="viewport" content="width=device-width, user-scalable=no"/>
<script type="text/javascript">
function reloadHref(url) {
setTimeout(() => window.location.href = url, 2000);
}
function reloadRedirect(url) {
setTimeout(() => window.location.replace(url), 2000);
}
</script>
</head>
<body>
<p><a href="javascript:reloadHref('https://duckduckgo.com');">
Simulate an HREF selection
</a></p>
<p><a href="javascript:reloadRedirect('https://duckduckgo.com');">
Simulate a redirect
</a></p>
</body>
</html>
Pretty straightforward stuff, but should do the trick. This allows me to test the effects of the URL being changed and record the results. In fact, let's get straight to the results. Here's what I found out by testing using this page:| Situation | Expected | Flag set |
|---|---|---|
| Open a URL using JavaScript simulating a HREF selection. | 0 | 0 |
| Open a URL using a JavaScript redirect. | 0 | 0 |
I do note however also notice that DuckDuckGo doesn't load correctly for these cases, so presumably there's still a problem with the headers here. I'll have to come back to that.
The inability to use the Back or Forwards buttons is also beginning to cause me trouble in day-to-day use, so now might be the time to fix that as well. Once I have I can test the remaining cases.
My suspicion is that the reason they don't work is related to this error that appears periodically when using the browser:
JavaScript error: resource://gre/modules/SessionStoreFunctions.jsm, line 105: NS_ERROR_FILE_NOT_FOUND:Here's the code in the file that's generating this error:
SessionStore.updateSessionStoreFromTablistener(
aBrowser,
aBrowsingContext,
aPermanentKey,
{ data: { windowstatechange: aData }, epoch: aEpoch }
);
It could be an error happening inside SessionStore.updateSessionStoreFromTablistener() but two reasons make me think this is unlikely. First the error message clearly targets the calling location and if the error were inside this method I'd expect the error message to reflect that instead. Second there isn't anything obvious in the updateSessionStoreFromTablistener() body that might be causing an error like this. No obvious file accesses or anything like that.A different possibility is that this, at the top of the SessionStoreFunctions.jsm file, is causing the problem:
XPCOMUtils.defineLazyModuleGetters(this, {
SessionStore: "resource:///modules/sessionstore/SessionStore.jsm",
});
This is a lazy getter, meaning that an attempt will be made to load the resource only at the point where a method from the module is used. Could it be that the SessionStore.jsm file is inaccessible? Then when a method from it is called the JavaScript interpreter tries to load the code in and fails, triggering the error.A quick search inside the omni archive suggests this file is indeed missing:
$ find . -iname "SessionStore.jsm" $ find . -iname "SessionStoreFunctions.jsm" ./omni/modules/SessionStoreFunctions.jsm $ find . -iname "Services.jsm" ./omni/modules/Services.jsmAs we can see, in contrast the SessionStoreFunctions.jsm and Services.jsm files are both present and correct. Well, present at least. To test out the theory that this is the problem I've parachuted the file into omni. First from my laptop:
$ scp gecko-dev/browser/components/sessionstore/SessionStore.jsm \
defaultuser@10.0.0.116:./omni/modules/sessionstore/
SessionStore.jsm 100% 209KB 1.3MB/s 00:00
[...]
And then on my phone:
$ ./omni.sh pack Omni action: pack Packing from: ./omni Packing to: /usr/lib64/xulrunner-qt5-91.9.1This hasn't fixed the Back and Forwards buttons, but it has resulted in a new error. The fact that this is error is now coming from inside SessionStore.jsm is encouraging.
JavaScript error: chrome://embedlite/content/embedhelper.js, line 259:
TypeError: sessionHistory is null
JavaScript error: resource:///modules/sessionstore/SessionStore.jsm, line 541:
NS_ERROR_FILE_NOT_FOUND:
Line 541 of SessionStore.jsm looks like this:
_globalState: new GlobalState(),This also looks lazy-getter-related, since the only other reference to GlobalState() in this file is at the top, in this chunk of lazy-getter code:
XPCOMUtils.defineLazyModuleGetters(this, {
AppConstants: "resource://gre/modules/AppConstants.jsm",
AsyncShutdown: "resource://gre/modules/AsyncShutdown.jsm",
BrowserWindowTracker: "resource:///modules/BrowserWindowTracker.jsm",
DevToolsShim: "chrome://devtools-startup/content/DevToolsShim.jsm",
E10SUtils: "resource://gre/modules/E10SUtils.jsm",
GlobalState: "resource:///modules/sessionstore/GlobalState.jsm",
HomePage: "resource:///modules/HomePage.jsm",
PrivacyFilter: "resource://gre/modules/sessionstore/PrivacyFilter.jsm",
PromiseUtils: "resource://gre/modules/PromiseUtils.jsm",
RunState: "resource:///modules/sessionstore/RunState.jsm",
SessionCookies: "resource:///modules/sessionstore/SessionCookies.jsm",
SessionFile: "resource:///modules/sessionstore/SessionFile.jsm",
SessionSaver: "resource:///modules/sessionstore/SessionSaver.jsm",
SessionStartup: "resource:///modules/sessionstore/SessionStartup.jsm",
TabAttributes: "resource:///modules/sessionstore/TabAttributes.jsm",
TabCrashHandler: "resource:///modules/ContentCrashHandlers.jsm",
TabState: "resource:///modules/sessionstore/TabState.jsm",
TabStateCache: "resource:///modules/sessionstore/TabStateCache.jsm",
TabStateFlusher: "resource:///modules/sessionstore/TabStateFlusher.jsm",
setTimeout: "resource://gre/modules/Timer.jsm",
});
Sure enough, when I check, the GlobalState.jsm file is missing. It looks like these missing files are ones referenced in gecko-dev/browser/components/sessionstore/moz.build:
EXTRA_JS_MODULES.sessionstore = [
"ContentRestore.jsm",
"ContentSessionStore.jsm",
"GlobalState.jsm",
"RecentlyClosedTabsAndWindowsMenuUtils.jsm",
"RunState.jsm",
"SessionCookies.jsm",
"SessionFile.jsm",
"SessionMigration.jsm",
"SessionSaver.jsm",
"SessionStartup.jsm",
"SessionStore.jsm",
"SessionWorker.js",
"SessionWorker.jsm",
"StartupPerformance.jsm",
"TabAttributes.jsm",
"TabState.jsm",
"TabStateCache.jsm",
"TabStateFlusher.jsm",
]
It's not at all clear to me why these files aren't being included. The problem must be arising because either they're not being included when they should be, or they're being accessed when they shouldn't be.But it's late now, so I'm going to have to figure that out tomorrow.
If you'd like to read any of my other gecko diary entries, they're all available on my Gecko-dev Diary page.
Comments
Uncover Disqus comments