Tag Archives: mouse

Things I’ve Learned This Week (April 13 – April 17, 2015)

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

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.

  1. And probably a bunch of other peripherals as well ↩

Mouseover / Mouseout on Nested Elements

Did I mention I’m code-sprinting over the next three days?  Actually, next two days – I just finished my first day today.

What’s code-sprinting?  It’s a trendy term for sitting down with your team, and plowing through code en masse, trying to get as much done as possible.  8 hour days, cookies, coffee, whiteboards, pizza, crashes, bugs, tickets, fixes, etc.  We’re trying to cram 3 weeks of work into 3 days.  Cool.

In case you don’t remember, I’m working on a project called Checkmark (or OLM…still undecided on the name) – a tool for Professors/TAs to receive student code submissions, and to facilitate easy marking and annotating of the submitted code.

So here’s something I learned today while coding:

Say you have some nested DIV’s, and the parent DIV has a mouseout trigger.  Something like this:

<div id="parent" onMouseOut="alert('Mouseout triggered on parent');">
  <div id="child_1">This is some child</div>
  <div id="child_2">This is another child</div>
</div>

As you would expect, the mouseout event will get triggered if you move your mouse over the parent DIV, and then move the mouse back out again.

But it also gets triggered when you move your mouse OVER any of the child DIV’s.

Say what?  That’s right – even though you’re still inside the parent DIV, the mouseout event got triggered.  I found this out today when I was trying to code dropdown menus in Javascript/CSS using Prototype – I could get the dropdown menus to appear find when I clicked on the appropriate button, but they’d disappear again as soon as I put my mouse over any of the sub-elements of the DIV.

So how did I fix this?  I found this example code, and adapted it for my purposes.  This code assumes that you’re using the Prototype Javascript library.

$('some_dropdown').observe('mouseout',
  function(event) {
     //We could probably replace the following with Event.element(event), but oh well.
     var target = $('some_dropdown');
     var mouse_over_element;  //What the mouse is currently over...
     //So let's check to see what the mouse is now over, and assign it to mouse_over_element...
     if( event.toElement ) {
        mouse_over_element = event.toElement;
     }
     else if(event.relatedTarget) {
       mouse_over_element = event.relatedTarget;
     }
     //In the event that the mouse is over something outside the DOM (like an alert window)...
     if(mouse_over_element == null) {
        return;
     }
     //Now we just make sure that what the mouse is currently over is NOT a descendant of
     //the dropdown, and that the target is not the current mouse_over_element (I can't
     //remember which case this covers, but it's important)
     if(!mouse_over_element.descendantOf(target) && target != mouse_over_element) {
        target.hide();
     }
   }
 );

And it works.  Whew!  Just thought I’d share that little snippit.