update external documentation hyperlinks sadly, a lot of interesting stuff has just evaporated. * Browser is no a custom element (MozBrowser) https://searchfox.org/mozilla-central/source/toolkit/content/widgets/browser-custom-element.js * Services.jsm is now built into the C++ core https://bugzilla.mozilla.org/show_bug.cgi?id=1464542
populate more data in contentAreaClick Bug 1800149 introduced ClickHandlerParent.fillInClickEvent() which we just inline. Previously, mozilla passed these params from the content process, which could be a problem if the content process was compromised Note that this code does not work with mozilla68 because window.browsingContext was only introduced afterwards. Further, for documentation: * until mozilla110, isContentWindowPrivate was calculated differently: https://hg.mozilla.org/mozilla-central/rev/a868f954be08#l1.51 * frameID used to use the same code as frameOuterWindowID in <=fx110: WebNavigationFrames.getFrameId(window.document.defaultView)
improve contentAreaClick This adds a few missing options used by BrowserUtils.whereToOpenLink, as well as finally passing CSP and ReferrerInfo. Unlike Mozilla, we call contentAreaClick directly from the parent process (they from ClickHandlerChild), so we don't need to serialize/deserialize these objects. However, they get CSP from event.originalTarget.ownerDocument and try to init ReferrerInfo from initWithNode(event.composedTarget), neither of which we have access to from the parent process. Note that referrerInfo.initWithDocument() was introduced with mozilla69: https://hg.mozilla.org/mozilla-central/rev/b5df2e6d8478cb4aea88d109259714ca2772b6cd#l1.29
port to ESMs and set minimum firefox version to 115 the last JSM we use, CustomizableUI, was ported to an ESM in mozilla115: https://hg.mozilla.org/mozilla-central/rev/e283f1653fee034bbe37c839c70d818173500f2b
stop relying on AddonManager.jsm for retrieving homepageURL this was always brittle (e.g. restarting the browser with the options page open would try to access homepageURL before it was available/loaded from async).
(half/full) page scrolling: don't take position:absolute headers into account Github's new code view[1] places each line of code visible on screen, as well as some above and below, as a position:absolute element (within a position:relative parent). Our code did not check whether such an element is absolute w.r.t the current scrolling viewport or some other element and would horribly miscalculate the amount to scroll: It would take all off-screen position:absolute elements and add their heights, then subtract that from the amount to scroll; even turning the scoll amount negative! Further, * medium[.]com does not appear to use any footer any more, and * the website mentioned in #698, inbound[.]org no longer resolves. The referenced Firefox implementation doesn't check position:absolute elements at all. As an actual improvement, Firefox now actually checks for position:sticky elements, but only when they are 'stuck' (and therefore behaving like position:fixed)[2]. They use some Gecko internals, but this could be implemented in VimFx using something along the lines of this: isStuck = (elem) => elem.getBoundingClientRect().top <= parseInt(getComputedStyle(elem).top) 1: https://github.blog/2023-06-21-crafting-a-better-faster-code-view/ 2: https://hg.mozilla.org/mozilla-central/rev/263936aecc1d
fix sandbox detection this was backwads. filesystem reads are blocked on level 3 or above. also renaming this function to better capture what it does (returns true if sandbox likely prevents config file access). see also: https://wiki.mozilla.org/Security/Sandbox#Linux https://searchfox.org/mozilla-central/search?q=security.sandbox.content.level&path=browser%2Fapp%2Fprofile%2Ffirefox.js