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.
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.
- 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.