I improved the waitForFocus function in bug 554873. This fixes problems with using waitForFocus when waiting for a new window to open. Instead, it waits for a non-blank page to load. If this is actually expected, a flag is available to alter this behaviour.
Other than that, I mostly worked on panel improvements again. I spent most of the week working on ensuring that the coordinates and position of panels are properly set when a titlebar is present.
Let’s say that you needed to write code that needs to store the position and size of two rectangles, and you wanted to store them in the most optimal way. But you didn’t want to optimize for space or for performance. Instead, you wanted to optimize for maximum confusion to someone reading your code eight years later. What would you do? The solution is obvious. Store only one rectangle but use the position of one rectangle and the size of the other. Or vice versa. And especially, mix and match the values at different times. Finally, have an aha moment when you realize it could be differently on each platform.
This is the way the window positioning and sizing code works. Luckily I discovered that I should be able to avoid having to deal with that confusion and handle things entirely in the popup code.
Now that that is mostly complete, I next plan to polish up the code and break it down into smaller patches to make it clearer as to which patch implements or fixes what popup feature.
Besides titlebars, a new floating panel will be available, by setting the level attribute on a panel to ‘floating’. This creates a panel suited for a floating panel such as a tool palette window on each platform. The exact behaviour will differ on each platform though due to available features of the underlying platform. Generally, the panel will appear on top of the parent window, can be moved independently of it, and on Mac, will hide when the application becomes inactive.
Checked in and worked on some additional followup issues with how focus rings are displayed. The intent is to display focus outline rings only when the system wants us to. Most notably, on Windows, focus rings only get displayed when a system setting is used, or the keyboard is used to open or navigate within a dialog. On Mac, elements do not focus themselves any more when clicked.
The new :-moz-focusring property pseudoclass only matches when a focus ring should be displayed.
I implemented a patch which uses some custom images for resizers in bug 554810. This improves the appearance when the textbox background colour is changed, on certain platforms and with right-to-left textboxes.
I am getting back into implementing more popup and panel features. The first feature allows one to retrieve the likely coordinates of where a popup will appear from within a popupshowing event using the getBoundingClientRect method or other similar methods. This will create the popup content and lay it out, which means that the popup could be laid out twice, however the popup layout will only occur twice if you actually need the information beforehand. In most situations, you don’t.
I then used this feature to start work on a generic arrow style of panel which has an arrow which points to its target. The arrow position updates to point in the right direction and be in the right position even when the popup opens in a different direction or position than expected.
The functions of the nsDragAndDrop.js script are currently used in browser.js in a couple of places. Most uses have been converted to the new drag and drop API. In bug 545119 I remove the last usages of this script from Firefox. This script and any of its functionality will not be available in browser code any more, unless you include it yourself, which you wouldn’t do, right?
- In bug 554873 I worked on getting waitForFocus to work more as expected.
- Merged some popup layout code in bug 562740.