cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jesse <>
Subject Re: Why does the Dialogs plugin in inject itself into navigator and has no browser support?
Date Thu, 14 Apr 2016 20:59:34 GMT
Notification pre-dates the use of plugin namespaces, most plugins
originally were hung off of navigator when a standard did not exist.
The notification plugin used to include things like displaying a loading
spinner, or vibrating the device, so it was much more about 'notifying'
than strictly dialogs.

The problem with alert on various platforms is it is not consistent. It
does not even exist on windows, it displays a title of 'index.html' on iOS,

The additions for browser are coming, or you could do it and send a pr ;)



On Thu, Apr 14, 2016 at 12:25 AM, Philipp Kursawe <>

> Hello,
> sometimes I wonder the historical reasons why certain cordova plugins
> choose to inject themself into "navigator" instead of their own namespace
> or remain at cordova.plugins.<pluginname>.
> For things where a native browser spec exists or is proposed like
> "geolocation" it makes sense. Then you can just code against the native
> browser API and when running on a device, that does not have this native
> support the Cordova geolocation plugin poly-fills that behaviour.
> I recently came across the "Dialogs" plugin which uses
> "navigator.notifications" and I wonder why?
> Why not "navigator.dialogs"? So I checked, maybe there is a W3C spec for
> browser notifications. There isn't.
> What is also interesting, that while browser have native support for alert
> and prompt at the window level, the plugin neither polyfills them nor
> provides any browser support at all.
> One could just write the application with "window.alert()" and on mobile
> devices the plugin would polyfill this behaviour.
> Any insides in the though process of those decisions?
> Thanks a lot!
> Phil

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message