Closed Bug 420661 Opened 17 years ago Closed 17 years ago

Add a web content accessible JS API for some set of runtime features

Categories

(Mozilla Labs :: Prism, defect)

Product:
Mozilla Labs
Component:
Prism
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: mfinkle, Assigned: mfinkle)

References

(Depends on 1 open bug)

Details

Attachments

(2 files, 1 obsolete file)

Simple example of using the API
645 bytes, text/plain
Details
Unbitrotted version of patch
16.10 KB, patch
mfinkle
: review-
Details | Diff | Splinter Review
Prism has several desktop-enabling features that are only exposed to chrome JS through XPCOM, We should create a simple JS API for a subset of features to expose the features to web content. * allow data passing (to support dock badging) * allow popup toaster/growl alerts * some form of local file drag-n-drop * dock/systray menu support
We should definitely use a namespace for the API. I'd like to stay as generic as possible so "prism" is out. Possibilities are "runtime" (AIR uses this), "platform" and "desktop". First pass methods could include: // show a popup toaster/growl alert showNotification(title, text, imageURL) - maybe we could have a callback for clicks - imageURL can be a data: URL - imageURL is optional // pass data to chrome postData(value, title) - could be used to badge icons or whatever the chrome supports - title is optional // notified of a local file drop We could look at using nsIDOMEventTarget / Listeners We might be supporting an IE, Safari, AIR model soon. See: http://wiki.mozilla.org/XUL:Specs:TransferData Thoughts?
Also, Mozilla now supports nsIDOMFile and nsIDOMFIleList which could also be useful for file drops
(In reply to comment #1) > We should definitely use a namespace for the API. I'd like to stay as generic > as possible so "prism" is out. Possibilities are "runtime" (AIR uses this), > "platform" and "desktop". I like "desktop" since we are talking about desktop integration. "Platform" and "runtime" are so generic they lose all meaning. > First pass methods could include: > > // show a popup toaster/growl alert > showNotification(title, text, imageURL) > - maybe we could have a callback for clicks > - imageURL can be a data: URL > - imageURL is optional I added an nsINotificationAreaListener interface as part of the tray icon code, but upon reflection I think that a DOMNotificationClicked event might be a better approach. > // pass data to chrome > postData(value, title) > - could be used to badge icons or whatever the chrome supports > - title is optional Once again, this sounds generic to me to the point of possibly being unclear. What other uses do you see for this besides badge icons? Maybe something like setApplicationStatus(name, value) would be more appropriate? > // notified of a local file drop > We could look at using nsIDOMEventTarget / Listeners > We might be supporting an IE, Safari, AIR model soon. See: > http://wiki.mozilla.org/XUL:Specs:TransferData This looks awesome. Definitely of great importance to Prism. Is someone currently working on implementing in Mozilla?
For me, "desktop" makes the most sense; it's an established abstraction on the major platforms and "platform" and "runtime" both sound broader, a bit like what should be used if larger parts of Mozilla was exposed (this is, in my mind, quite specific: narrow the gap between web and desktop applications). Of course, it would then be absolutely necessary to maintain the scope of desktop integration for whatever functionality gets put into this namespace. I don't know what the potential risks of feature creep are, if any. As for the suggested first API, it's just postData I'm unsure about, more specifically if it should relate to features common to the major platforms or not. (It could be the name that throws me off, postData has a very generic feel to it.)
So, basically it appears I agree with Matt. ;)
Remember that we are potential going to use the same web API from Firefox (and other browsers) too. So I'd like to stay more generic and less specific :) "desktop" might be ok, but could be too specific for a traditional browser. Yeah, "postData" is likely too generic. "setApplicationStatus(name, value)" is ok, but I like "post" prefix since we are merely passing data to the chrome - we don't know what, if anything, will be done with the data. I also like "data" better than "status", so how about: postApplicationData(name, value); I guess I felt "Application" was a bit redundant, hence "postData" :) I also think that a DOMNotificationClicked event might be a better approach for handling click notifications.
How about "application"? Since it is a way for web content to get access to what's commonly thought of as application-level features. It's also fairly broad without sounding like it encapsulates anything beyond the application itself (as with "platform").
What I meant to say was: as _is the case_ with "platform".
"desktop" is too specific, since Firefox and other web browsers can usefully implement this API, and future browsing environments may not have a desktop to speak of. "platform" and "runtime" both seem fine to me, but "application" is a bit overloaded and thus ambiguous. Regarding method names, "showNotification" seems fine, but, as others mentioned, "postData" is vague. I prefer "setStatus" or the like, and it doesn't seem to me that such a name implies anything about what the browsing environment is going to do with the information.
Well a browser can interact with the desktop too. Interesting point about future browsing environments but I think we can assume for now that there will be something analogous to the desktop to hang that term on. Strongly in favor of "desktop" since it gives some meaning and scope to the APIs, but of course I can live with the other variants.
Another case for not using "desktop" I just thought of is the mobile space. There is no comparable desktop metaphor for most mobile platforms. Symbian doesn't have it, neither does Android (I'm a bit unsure about Windows Mobile but I don't think they use it to refer to the mobile OS environment). Generally, when talking about mobile platforms, "desktop" is used as a clear differentiator, it denotes something that happens outside the phone itself, on the "desktop computer". Mozilla Mobile is a project that can't be overlooked for virtually any new API that may some be implemented by the browser product, IMHO. Between "platform" and "runtime" I feel "platform" has the right connotations for what the API will actually accomplish.
(In reply to comment #11) > Well a browser can interact with the desktop too. Yes, but these APIs won't necessarily use the desktop when implemented by a browser. For example, a browser might implement badges as tab labels, and it might implement notifications via an in-browser method like the one faaborg has proposed <http://blog.mozilla.com/faaborg/2007/03/06/would-you-like-to-redesign-notification-in-firefox-yes.-not-now.-never./>. Even an API for dropping a file isn't necessarily desktop-specific, since browsers might support tab-to-tab drag and drop of files and other information. > Interesting point about future browsing environments but I think we can > assume for now that there will be something analogous to the desktop to hang > that term on. Indeed, the problem is just that the word "desktop" won't describe it accurately. If that doesn't matter, then we might as well use the existing "navigator" namespace.
Let's go with "platform".
This patch adds a basic web content JS API for desktop enabling. The nsIPlatformGlue.idl file has the details of the API. Note that bug 304048 keeps us from using child properties ("sound" in the IDL for example). Instead we need to use a function to return the child object. We get permission errors if we do not.
Assignee: nobody → mark.finkle
Status: NEW → ASSIGNED
Depends on: 304048
Very basic HTML scripting example that uses parts of the API
What the hell? When did we decide it was OK to add new content features through Prism? Is any of this stuff being proposed for inclusion in Gecko, or publicly discussed? "This app requires Prism" is crap that we should avoid at all costs, and giving Prism-hosted apps special capabilities like drag-and-drop is exactly, EXACTLY where that leads. If we want an "experimental web features" extension somewhere, I don't think there will be any trouble getting people behind it, but people should _not_ be installing Prism in order to get some experimental web technology, and Prism should not, IMO, be a dumping ground for such experiments. People should be installing Prism to get web applications launched in a site-specific way, with independent processes and configurations. I do not at all understand why this is a Prism-specific bug; if these capabilities are useful to web applications, we should be discussing them in the context of Gecko and the broader web. If nothing else, the API names should have "experimental" and "mozilla" or "prism" (but no, because see above -- this isn't _about_ Prism, except that people happened to already have it open in their editors) all over them. If nothing else, please move this bug to the DOM component.
I passionately disagree. This should be about technology, not about ideology or politics. As the original Prism blog post states, the project is an experiment "to bridge the divide in the user experience between web applications and desktop apps and to explore new usability models as the line between traditional desktop and new web applications continues to blur." So let's experiment. We have a small but highly motivated team working on this. Why kill off the momentum we have? What I've gathered from multiple discussions with multiple people is that the real issue is intense concern that Mozilla will open itself up to accusations of hypocrisy since the aforementioned blog post goes out of its way to say that "unlike Adobe AIR and Microsoft Silverlight, we’re not building a proprietary platform to replace the web." Well, if this is true then let me set your mind at ease: this statement is absolutely true and accurate with respect to the work we are doing on Prism. Prism is based on HTML, HTTP, JavaScript; all the web standards we know and love. No Flex, no MXML, no Flash, no XAML, no .NET. The idea that what we are working on is somehow contradictory to the open web is flat out wrong. As far as proprietary platforms are concerned, Firefox extensions are a much more appropriate example. Personally I love XUL, XPCOM, XPI, XBL and all the other Xs, but it's hard for me to see how they are somehow okay when prototyping some new JavaScript APIs as part of the Prism experiment is not.
I agree with Matt. This is an experiment in providing extra features for desktop-enabled web apps. If it's a successful experiment, we can port the code back to our core, or implement it as a Firefox extension, or whatever. But saying "prism ought not to provide any extra content-visible APIs" is silly.
Citing the original blog post doesn't help your case, as when we were writing it (and I was part of that group, about this _very_ topic), we were quite clear that we didn't want to use Prism as a vector for different app capabilities. But if you're going to cite it, cite it more fully: "Mozilla Labs is launching a series of experiments to bridge the divide in the user experience between web applications and desktop apps and to explore new usability models as the line between traditional desktop and new web applications continues to blur. [...] Prism is an application that lets users split web applications out of their browser and run them directly on their desktop. [...] Prism isn’t a new platform, it’s simply the web platform integrated into the desktop experience." The post also describes _other_ experiments to add new content features: "And while Prism focuses on how web apps can integrate into the desktop experience, we’re also working to increase the capabilities of those apps[...]." Prism is a bad way to deploy experimental content features, because the point of an experiment is to get results that help us improve the feature, and the results in this case need to come from developers. But developing a web app under Prism is a major step back from developing it under Firefox: you have to do big hacks to get Firebug working or open other tabs or _reload_. If we are serious about wanting to improve the web platform in these areas, and I very much think we should be, then we should do it in a way that's going to get us better feedback. It's not clear at all to me why wedging them into Prism is better than putting them in an extension -- which could be installed in Prism for people who wanted to test the app there, but shouldn't be necessary for feedback, because Prism can run whatever Firefox can run, right? If _nothing_ else, these APIs should be clearly marked as experimental and proprietary in their naming, like we did with mozDrawText on Canvas and the XUL namespace and -moz-box in CSS. And if we're doing them as _experiments_, let's see some docs and tests so we get value out of the experiment.
(In reply to comment #20) > Citing the original blog post doesn't help your case, as when we were writing > it (and I was part of that group, about this _very_ topic), we were quite clear > that we didn't want to use Prism as a vector for different app capabilities. > > But if you're going to cite it, cite it more fully: > > "Mozilla Labs is launching a series of experiments to bridge the divide in the > user experience between web applications and desktop apps and to explore new > usability models as the line between traditional desktop and new web > applications continues to blur. [...] > Prism isn’t a new platform, it’s simply the web platform integrated into > the desktop experience." Totally agree with all of this. I don't think the work done in the context of this bug contradicts any of that. > Prism is a bad way to deploy experimental content features, because the point > of an experiment is to get results that help us improve the feature, and the > results in this case need to come from developers. But developing a web app > under Prism is a major step back from developing it under Firefox: you have to > do big hacks to get Firebug working or open other tabs or _reload_. That Firebug doesn't work in Prism or that Prism doesn't handle tabs properly are bugs that should be fixed. In any case, I don't expect people to develop "a web app under Prism." I expect them to augment their existing web apps with additional capabilities, using Prism as a testbed. We should try to design good, clean APIs for these capabilities. > If we are serious about wanting to improve the web platform in these areas, and > I very much think we should be, then we should do it in a way that's going to > get us better feedback. It's not clear at all to me why wedging them into > Prism is better than putting them in an extension -- which could be installed > in Prism for people who wanted to test the app there, but shouldn't be > necessary for feedback, because Prism can run whatever Firefox can run, right? The reason that I think Prism is the right place to experiment with these features is that it enables us to benefit from a tight feedback loop from the people who are going to be using this stuff. From my experience working on Prism, it is clear that there are a large number of people who are extremely enthusiastic about the project. These enthusiastic Prism fans see it as an open, Mozilla-based alternative to AIR, Fluid, Google Gears and the like. They are telling us what features they want in order for it to be effective in this regard, and we are benefiting greatly from this feedback. I've certainly taken to heart the comments I've heard from you guys about making sure the resulting APIs are web-friendly and appropriate for use in Firefox and elsewhere. But I still think that Prism is the right place to experiment with them. I don't think we'd get the same level of interest, support and feedback otherwise. That said, if we put them into an extension and ship Prism with that extension preinstalled, no one will notice the difference. I don't personally see this as being particularly worthwhile but if you feel strongly about it, I don't mind personally. Note that we are absolutely commited to folding everything we've done on Prism into the appropriate places in the Mozilla stack (e.g. my OS integration stuff should probably live in Toolkit). This is just a chance to leverage great community response to design and experiment with these new capabilities in a way that benefits real web developers, instead of trying to perform a challenging design exercise in a vacuum. > If _nothing_ else, these APIs should be clearly marked as experimental and > proprietary in their naming, like we did with mozDrawText on Canvas and the XUL > namespace and -moz-box in CSS. And if we're doing them as _experiments_, let's > see some docs and tests so we get value out of the experiment. Personally I'm happy to call the APIs whatever you want.
Actually, there is one reason to avoid the extension approach, which is testing burden. Right now, any changes to Prism have to be tested both in the Prism4Firefox extension and in Prism itself, on Mac, Windows and Linux. Having to test in Firefox as well will greatly increase the testing effort. If we can get some support from QA that would alleviate this, of course. Otherwise it might make more sense to use Prism as the testbed, get everything working there and then port to Firefox as a separate development effort.
(In reply to comment #17) > What the hell? When did we decide it was OK to add new content features > through Prism? Is any of this stuff being proposed for inclusion in Gecko, or > publicly discussed? I think it's ok to prototype experimental new content features through Prism as long as they aren't Prism-specific or -focused. All of this stuff is being proposed for inclusion not just in Gecko but in the web platform generally, and it is being publicly discussed here in this bug and on the Prism forum <https://labs.mozilla.com/forum/index.php/board,16.0.html>. > "This app requires Prism" is crap that we should avoid at all costs Agreed. > and giving Prism-hosted apps special capabilities like drag-and-drop is > exactly, EXACTLY where that leads. That's a danger, and the way to avoid it is to: 1. design these features to be web platform features, not Prism features; 2. work with other browser (both classic and "SSB") vendors to promote their standardization; 3. drive Prism from a separate runtime to a Firefox extension and thence to a core Firefox feature whose web platform extensions are available in all its browsing environments. > I do not at all understand why this is a Prism-specific bug; if these > capabilities are useful to web applications, we should be discussing them in > the context of Gecko and the broader web. Indeed, we should be having those discussions. > If nothing else, the API names should have "experimental" and "mozilla" or > "prism" (but no, because see above -- this isn't _about_ Prism, except that > people happened to already have it open in their editors) all over them. Labeling these APIs "experimental" seems fine. Labeling them "mozilla" or "prism" doesn't, however, given that they are explicitly designed not to be Mozilla- or Prism-specific, unless your suggestion is to follow the -moz-foo -> foo transition of some of our CSS proposals, for which I don't know enough context to be able to comment on applicability in this case. > If nothing else, please move this bug to the DOM component. Sounds good to me, although it makes sense to have a separate bug tracking experimental implementation in Prism, which this one has been so far, so we might as well file a new bug for the Gecko implementation.
WebApp has requested the ability to send notifcations to you on your desktop. Allow? Allowing this lets you be able to use tooltip/growl messages above your tooltray.
I would much prefer for Firefox to notify in-browser, but configurable to hand off to growl on mac / toast on windows. That way it always works, with no annoying popup questions.
Dan, self-made notifications make inconsistence. Current Firefox' notifications are unuseable: * they're sliding down instead of fading out * they're not stopping animation when hovered * link is used instead of button (bigger clickable area) They need to be removed as quick as possible. libnotify provides nice features, like: * time limit displayed with a little pie chart * displaying buttons with custom label and actions (not sure how about icons) * pausing time limit when hovered * "attached" notifications or stacked (firefox has only stacked) * buttons instead of links (opensuse uses notification-daemon's theme with links - heavily unuseable and buggy) Assuming, I'll not agree to keep current notifications or cancel using libnotify.
I'm not sure we are talking about the same things (?). I just pointed out that instead of the browser being expected to always hand out notifications to the platform, it could very well implement something (new, which we do not have yet) in-browser. e.g., this could integrate or build upon: http://blog.mozilla.com/faaborg/2007/03/06/would-you-like-to-redesign-notification-in-firefox-yes.-not-now.-never./ Additionally, we'd still have the freedom to delegate any or all notifications to the platform. For example, maybe I could tell Firefox on my phone to use the phone's notification mechanism to beep when gmail.com notifies me I have new mail. But it would be my choice to do so, not the website's.
(In reply to comment #27) > I just pointed out that instead of the browser being expected to always hand > out notifications to the platform, it could very well implement something (new, > which we do not have yet) in-browser. e.g., this could integrate or build upon: > > http://blog.mozilla.com/faaborg/2007/03/06/would-you-like-to-redesign-notification-in-firefox-yes.-not-now.-never./ > > Additionally, we'd still have the freedom to delegate any or all notifications > to the platform. For example, maybe I could tell Firefox on my phone to use > the phone's notification mechanism to beep when gmail.com notifies me I have > new mail. But it would be my choice to do so, not the website's. > Agreed. The manner in which the notifications (or any part of the API) are implemented depend on the host (Firefox vs Prism) and the platform (Win/Mac/Linux and PC/Mobile).
I also moved nsCommandHandler.js into runtime/components/src to be consistent with nsPlatformGlue.js.
Attachment #308192 - Attachment is obsolete: true
Comment on attachment 317521 [details] [diff] [review] Unbitrotted version of patch remove postStatus from the API. We will be using microformats in content to handle that feature.
Attachment #317521 - Flags: review-
Folded into bug 415948.
Status: ASSIGNED → RESOLVED
Closed: 17 years ago
Depends on: 415948
Resolution: --- → FIXED
I think Prism for the name is fine. Mozilla Prism sounds pretty good. Its just like Mozilla Firefox. Who would guess Firefox is a browser?
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: