The interview article is mainly for addon developers, this is the reason of the answer for the question. In past days I was a "people pleaser" and I didn't say "no" from my frailty, then my old addon became too fat, and finally dead. I hope that addon authors publish long-living small addons instead of short-live too much addons.
The sentence in the interview means that now there is a boundary of responsibility between addon and Firefox. If a feature request is impossible to be implemented due to API restrictions, it have to be solved by Firefox itself. Thus if I have strong motivation to implement a new feature requiring new API, I still file a proposal of new API, and I think other addon authors also should do it based on his demand.
There are two reasons, the first is there. The second reason is my job. I'm employed as a support engineer for company-use of Firefox/Thunderbird for 11-12 years, and the knowledge and trust are based on my addon development experience. So, I think I already monetized from addons and donation looks like a double-dealing for me now. (So after I retired I may accept donation, if Firefox and my addons still alive.) Anyway, I just say thanks to all!
As I wrote in the article, indeed I worried about death of addons in last 2 years. But, from various viewpoints I analyzed Mozilla's statements around addons, and finally I decided to forget past and shift my mind moving toward to make things better. So the story of the interview is almost correct.
Thanks for all your work. If you had a donation option, I'd be happy to limit my contribution to what I've gained from the past ~10 years of usage with literally no expectation of continued development.
I really appreciate you writing up and sharing your migration story and raw opinions, as well as all the great code you've written. Thanks you!
I've done some xulrunner app development as well as IE ActiveX control browser extensions in the past, including various implementations of pie menus, and I would like to learn more about the latest Firefox, Chrome and Safari extensions APIs, so I can implement pie menus properly for those platforms.
That's why I'm so happy to be able to read your migration story and raw opinions! Reading about you experience is even more valuable than reading the source code itself! Thank you again! ;)
I've implemented pie menus in jQuery for web pages [1] [2], but they really need to be rendered with transparency in their own arbitrarily shaped popup overlay windows, so they're not confined to the browser window, like I was able to do with ActiveX controls in C++/MFC and also X11/TCL/Tk back in the 90's [3], and with NeWS in PostScript back in the 80's [4].
I noticed that Safari extensions have an API for creating popover windows called SafariExtensionPopover [5] [6] [7]. But they must be rectangular, and the documentation doesn't mention how their position is defined (but I presume they appear beneath the cursor or invoking toolbar item). So there doesn't seem to be an obvious way to position or shape them. (Could you get the popover's window, and set its position pixel-perfectly regardless of borders?)
As far as I can tell, Safari's popovers are only good for traditional linear menus that pop up below the cursor or toolbar item, because you can't even control their position to center them on the cursor like a pie menu requires.
Do you know if there any way to create a pop-up window in any position or size, and even to set the background color transparent, so I can make arbitrarily shaped and popup windows? Even rectangular overlapping popup windows would be better than having to clip them to the window frame.
Do you have any suggestions for how I should approach the problem, please? What kind of browser extension API do you think could be designed or modified to support arbitrarily shaped pop-up windows for pie menus and other techniques (like tabs sticking out the edge of the window [9], for example)?
(The X-Windows SHAPES extension [10] is a terrible example of the worst possible way of doing that! ;) )
You can use native messaging to send a message to a script or executable that crates that arbitrary and transparent window. Nothing inside webext allows you to do exactly what you are looking for though from inside the webext.
The sentence in the interview means that now there is a boundary of responsibility between addon and Firefox. If a feature request is impossible to be implemented due to API restrictions, it have to be solved by Firefox itself. Thus if I have strong motivation to implement a new feature requiring new API, I still file a proposal of new API, and I think other addon authors also should do it based on his demand.