Neil's Place

July 5, 2010

Status Update for July 5

Filed under: Mozilla, Status Updates — enndeakin @ 3:34 pm

Last week, I finished off the support for titlebars in popup panels. This will add three new attributes to the <panel> element: titlebar, close and label, as well as a new floating value for the level attribute.

The -moz-resize property to make elements resizable has been changed to resize to be compatible with Webkit.

Other bugs:

  • Bug 551434 – keypress and keyup events should fire at the same element as the keydown event.
  • Bug 558072 – rework popup opening and layout so that the likely coordinates that the popup will open at are available within the popupshowing event.
  • Bug 564277 – implement better focus ring behaviour for html elements.

May 22, 2010

Status Update for May 21

Filed under: Mozilla, Status Updates — enndeakin @ 1:32 am

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.

May 7, 2010

Status Update for May 7

Filed under: Mozilla, Status Updates — enndeakin @ 10:21 pm

Focus Rings

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.

Resizers

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.

Popups

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.

nsDragAndDrop.js

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?

Other

  • In bug 554873 I worked on getting waitForFocus to work more as expected.
  • Merged some popup layout code in bug 562740.

April 18, 2010

Status Update for April 18

Filed under: Mozilla, Status Updates — enndeakin @ 7:03 pm

Dropped Link Handling

I just checked in some notable changes to how the browser handles dropped links. It shouldn’t affect the behaviour of dropped links, but it does affect how script would respond to dropped links. This involves a new interface nsIDroppedLinkHandler. From an extension, one can use this directly or import the Services.jsm script and just access it via ‘Services.droppedLinkHandler’.

For browser front-end developers, this means that the single object located in browser.js will handle dropped links. This object and its related helper component will determine if a link is being dropped and whether security allows it to be dropped. This is important as one doesn’t want to be able to just create a page with a chrome url that can be dropped on the browser to do some nefarious thing. The old way used the nsDragAndDrop.js script for this, which is now obsolete.

See bug 545714 for more information about these changes.

The nsDragAndDrop.js script and its security check are now not used, except in one place in the tabbrowser which will be fixed up soon.

Resizers

A number of theme issues with resizers need to be fixed up (bugs 553796, 553752, 554810 and 558201. It seems like the best way to fix these is to include some static resizer images instead of relying on the native theme. I have a fix but need some images that are suitable for each platform.

Other

  • In bug 554635, <object> elements are been given a default tabindex of 0 so that they can be tabbed into. Those that load plugins already default to 0 so this applies to those that load other pages.
  • For bug 559561, I was investigating firing blur events when focused elements are removed from a document.
  • Took a short break from panel bugs this week. More to come next week.

April 9, 2010

Status Update for April 9

Filed under: Mozilla, Status Updates — enndeakin @ 10:16 pm

Improvements to panels are going steadily. I have worked out the issues with coordinate calculations on both Windows and Mac. This means that panels with titlebars appear and work properly. I also think I’ve almost worked out how popup activation and focusing should work. More details of what steps need to be done are on the Panel Improvements page.

I also have been investigating better support for the arrow style popups. These display an arrow that points to an element which can be used to get further information or perform actions related to the popup. I’m working on making the arrow properly position itself even when the popup itself is pushed around to fit on screen. See bug 554937 for this feature, and bug 558072 for some preliminary work.

Bug 379745 adds support for templates and to the sort service for setting three special sort hints. The first allows one to sort by integers instead of strings, overriding the type of the data. The second allows case sensitive sorting, which probably isn’t as useful except for file listings on some systems. The third allows only sorting in ascending or descending order, and not having the natural sort state. This is accomplished via attributes placed on the root element, or the <treecol> element.

Also, I investigated some minor focus issues and resizer rendering problems. For instance, in bug 554635, it was discovered that <object> elements default to not being focusable.

« Newer Posts

Theme: Shocking Blue Green. Blog at WordPress.com.

Follow

Get every new post delivered to your Inbox.