When you send a sync message from a frame script to the parent, the return value is always an array
Example:
// Some contrived code in the browser
let browser = gBrowser.selectedBrowser;
browser.messageManager.addMessageListener("GIMMEFUE,GIMMEFAI", function onMessage(message) {
return "GIMMEDABAJABAZA";
});
// Frame script that runs in the browser
let result = sendSendMessage("GIMMEFUE,GIMMEFAI");
console.log(result[0]);
// Writes to the console: GIMMEDABAJABAZA
From the documentation:
Because a single message can be received by more than one listener, the return value of sendSyncMessage() is an array of all the values returned from every listener, even if it only contains a single value.
I don’t use sync messages from frame scripts a lot, so this was news to me.
You can use [cocoaEvent hasPreciciseScrollingDeltas] to differentiate between scrollWheel events from a mouse and a trackpad
scrollWheel events can come from a standard mouse or a trackpad1. According to this Stack Overflow post, one potential way of differentiating between the scrollWheel events coming from a mouse, and the scrollWheel events coming from a trackpad is by calling:
bool isTrackpad = [theEvent hasPreciseScrollingDeltas];
since mouse scrollWheel is usually line-scroll, whereas trackpads (and Magic Mouse) are pixel scroll.
The srcdoc attribute for iframes lets you easily load content into an iframe via a string
It’s been a while since I’ve done web development, so I hadn’t heard of srcdoc before. It was introduced as part of the HTML5 standard, and is defined as:
The content of the page that the embedded context is to contain. This attribute is expected to be used together with the sandbox and seamless attributes. If a browser supports the srcdoc attribute, it will override the content specified in the src attribute (if present). If a browser does NOT support the srcdoc attribute, it will show the file specified in the src attribute instead (if present).
So that’s an easy way to inject some string-ified HTML content into an iframe.
Primitives on IPDL structs are not initialized automatically
I believe this is true for structs in C and C++ (and probably some other languages) in general, but primitives on IPDL structs do not get initialized automatically when the struct is instantiated. That means that things like booleans carry random memory values in them until they’re set. Having spent most of my time in JavaScript, I found that a bit surprising, but I’ve gotten used to it. I’m slowly getting more comfortable working lower-level.
This was the ultimate cause of this crasher bug that dbaron was running into while exercising the e10s printing code on a debug Nightly build on Linux.
This bug was opened to investigate initializing the primitives on IPDL structs automatically.
Networking is ultimately done in the parent process in multi-process Firefox
All network requests are proxied to the parent, which serializes the results back down to the child. Here’s the IPDL protocol for the proxy.
On bi-directional text and RTL
gw280 and I noticed that in single-process Firefox, a <select> dropdown set with dir=”rtl”, containing an <option> with the value “A)” would render the option as “(A”.
If the value was “A) Something else”, the string would come out unchanged.
We were curious to know why this flipping around was happening. It turned out that this is called “BiDi”, and some documentation for it is here.
If you want to see an interesting demonstration of BiDi, click this link, and then resize the browser window to reflow the text. Interesting to see where the period on that last line goes, no?
It might look strange to someone coming from a LTR language, but apparently it makes sense if you’re used to RTL.
I had not known that.
Some terminal spew
Now what’s all this?
My friend and colleague Mike Hoye showed me the above screenshot upon coming into work earlier this week. He had apparently launched Nightly from the terminal, and at some point, all that stuff just showed up.
“What is all of that?”, he had asked me.
I hadn’t the foggiest idea – but a quick DXR showed basic_code_modules.cc inside Breakpad, the tool used to generate crash reports when things go wrong.
I referred him to bsmedberg, since that fellow knows tons about crash reporting.
Later that day, mhoye got back to me, and told me that apparently this was output spew from Firefox’s plugin hang detection code. Mystery solved!
So if you’re running Firefox from the terminal, and suddenly see some basic_code_modules.cc stuff show up… a plugin you’re running probably locked up, and Firefox shanked it.
And probably a bunch of other peripherals as well ↩
