The Joy of Coding (Ep. 9): More View Source Hacking!

In this episode1, I continued the work we had started in Episode 8, by trying to make it so that we don’t hit the network when viewing the source of a page in multi-process Firefox.

It was a little bit of a slog – after some thinking, I decided to undo some of the work we had done in the previous episode, and then I set up the messaging infrastructure for talking to the remote browser in the view source window.

I also rebased and landed a patch that we had written in the previous episode, after fixing up some nits2.

Then, I (re)-learned that flipping the “remote” attribute of a browser is not enough in order for it to run out-of-process; I have to remove it from the DOM, and then re-add it. And once it’s been re-added, I have to reload any frame scripts that I had loaded in the previous incarnation of the browser.

Anyhow, by the end of the episode, we were able to view the source from a remote browser inside a remote view source browser!3 That’s a pretty big deal!

Episode Agenda

References

Bug 1025146 – [e10s] Never load the source off of the network when viewing source – Notes

  1. A note that I also tried an experiment where I keep my camera running during the entire session, and place the feed into the bottom right-hand corner of the recording. It looks like there were some synchronization issues between audio and video, which are a bit irritating. Sorry about that! I’ll see what I can do about that. ↩

  2. and dropping a nit having conversed with :gabor about it ↩

  3. We were still loading it off the network though, so I need to figure out what’s going on there in the next episode. ↩

Things I’ve Learned This Week (March 30 – April 3, 2015)

This is my second post in a weekly series, where I attempt to distill my week down into some lessons or facts that I’ve picked up. Let’s get to it!

ES6 – what’s safe to use in browser development?

As of March 27, 2015, ES6 classes are still not yet safe for use in production browser code. There’s code to support them in Firefox, but they’re Nightly-only behind a build-time pref.

Array.prototype.includes and ArrayBuffer.transfer are also Nightly only at this time.

However, any of the rest of the ES6 Harmony work currently implemented by Nightly is fair-game for use, according to jorendorff. The JS team is also working on a Wiki page to tell us Firefox developers what ES6 stuff is safe for use and what is not.

Getting a profile from a hung process

Update [January 23rd, 2017]: Markus Stange contacted me to let me know that the function mozilla_sampler_save_profile_to_file has been changed to profiler_save_profile_to_file. This happened in this bug. I’ve updated the post to reflect this.

According to mstange, it is possible to get profiles from hung Firefox processes using lldb1.

  1. After the process has hung, attach lldb.
  2. Type in2, : 
    p (void)profiler_save_profile_to_file("somepath/profile.txt")
  3. Clone mstange’s handy profile analysis repository.
  4. Run: 
    python symbolicate_profile.py somepath/profile.txt

    To graft symbols into the profile. mstange’s scripts do some fairly clever things to get those symbols – if your Firefox was built by Mozilla, then it will retrieve the symbols from the Mozilla symbol server. If you built Firefox yourself, it will attempt to use some cleverness3 to grab the symbols from your binary.

    Your profile will now, hopefully, be updated with symbols.

    Then, load up Cleopatra, and upload the profile.

    I haven’t yet had the opportunity to try this, but I hope to next week. I’d be eager to hear people’s experience giving this a go – it might be a great tool in determining what’s going on in Firefox when it’s hung4!

Parameter vs. Argument

I noticed that when I talked about “things that I passed to functions5”, I would use “arguments” and “parameters” interchangeably. I recently learned that there is more to those terms than I had originally thought.

According to this MSDN article, an argument is what is passed in to a function by a caller. To the function, it has received parameters. It’s like two sides of a coin. Or, as the article puts it, like cars and parking spaces:

You can think of the parameter as a parking space and the argument as an automobile. Just as different automobiles can park in a parking space at different times, the calling code can pass a different argument to the same parameter every time that it calls the procedure.6

Not that it really makes much difference, but I like knowing the details.

  1. Unfortunately, this technique will not work for Windows. 🙁  ↩

  2. Assuming you’re running a build after this revision landed. ↩

  3. A binary called dump_syms_mac in mstange’s toolkit, and nm on Linux ↩

  4. I’m particularly interested in knowing if we can get Javascript stacks via this technique – I can see that being particularly useful with hung content processes. ↩

  5. Or methods. ↩

  6. Source ↩

The Joy of Coding (Ep. 8): View Source Hacking

In this episode, I again started with some code review. I reviewed this patch for this bug by fellow Firefox hacker Gijs, and refreshed my memory on var hoisting. I’ve been using let for so long that it was really, really weird to see how var worked.

After that, I quickly gave an update on my plugin crash UI bug I had been working on the last episode – the patches are up, and are currently undergoing review, so there wasn’t much to do there.

Next, I started on a brand new bug1, explained the bug2, and then laid out my plan for attacking it.

Specifically, I’m going to try an experiment: I will only be working on that bug during Joy of Coding sessions. That way, there is continuity from video to video, and you won’t miss any of the development that goes on between episodes.

We sliced off a chunk to get done, and hit some minor roadblocks (as expected). The View Source code is old and crufty, and I have to do my best to make sure I don’t break any of the other applications that depend on it (like Thunderbird and SeaMonkey).

So that was the name of the game – looking to see how other applications use View Source, and trying to come up with a plan for making sure we don’t break them, while at the same time refactoring View Source to be easier to code against (and work with a frame script and messages).

It was a long slog3, but we got to a good point by the end. Let’s see how far we get next week!

Episode Agenda

References

Bug 1148807 – Method moveToAlertPosition in dialog.xml should check if opener is not null

Bug 1110887 – With e10s, plugin crash submit UI is broken – Notes

Bug 1025146 – [e10s] Never load the source off of the network when viewing source – Notes

  1. I say brand new, except that, as I explain in the video, I had already attacked this bug early on in my e10s work, and had only recently come back to it. ↩

  2. The View Source tool sometimes re-retrieves the source off of the network when opened from an e10s-browser ↩

  3. My longest episode ever, clocking in at over 2.5 hours. ↩

Things I’ve Learned This Week (March 23 – 27, 2015)

This is the first post in a weekly series, where I’m going to attempt to distill down my week into some lessons or facts I’ve picked up. Maybe they’ll be interesting to others. We’ll see.

  1.  Gecko Media Plugins are used both for WebRTC (the Open H.264 encoding stuff runs inside a GMP), and is also going to be used to hold CDM’s for EME’s. That’s a lot of TLA’s!1
  2. This little notch I saw on the caret on my development build was because I had bidi.browser.ui set to true for some reason. It’s the “bidi caret”:
    Bidi Caret
  3. People hacking on platform are supposed to avoid using the NS_ENSURE_* macros, according to this.2 I originally learned this by reading cpearce’s review of a patch.

So let’s see if I can keep this up for a few weeks. Maybe I’ll get a collection of useful stuff by the end of the experiment!

  1. Three Letter Acronyms ↩

  2. It says:

    Previously the NS_ENSURE_* macros were used for this purpose, but those macros hide return statements and should not be used in new code.

     ↩

The Joy of Coding (Episode 7): Code review, and a Regression

In this episode, I started with some code review. I was reviewing a patch to make the Findbar (particularly, the Find As You Type feature) e10s-friendly.

With that review out of the way, I had to swap a bunch of information about the plugin crash UI for e10s in my head – and in particular, some non-determinism that we have to handle. I explained that stuff (and hopefully didn’t spend too much time on it).

Then, I showed how far I’d gotten with the plugin crash UI for e10s. I was able to submit a crash report, but I found I wasn’t able to type into the comment text area.

After a while, I noticed that I couldn’t type into the comment text area on Nightly, even without my patch. And then I reproduced it in Aurora. And then in Beta. Luckily, I couldn’t reproduce it in Release – but with Beta transitioning to Release in only a few days, I didn’t have a lot of time to get a bug on file to shine some light on it.

Luckily, our brilliant Steven Michaud was on the case, and has just landed a patch to fix this. Talk about fast work!

Episode Agenda

References:
Bug 1133981 – [e10s] Stop sending unsafe CPOWs after the findbar has been closed in a remote browser

Bug 1110887 – With e10s, plugin crash submit UI is broken – Notes

Bug 1147521 – Cannot type into comment area of plugin crash UI