[ 
https://issues.apache.org/jira/browse/CB-9449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14654412#comment-14654412
 ] 

ASF GitHub Bot commented on CB-9449:
------------------------------------

Github user purplecabbage commented on the pull request:

    
https://github.com/apache/cordova-plugin-dialogs/pull/55#issuecomment-127771911
  
    good additions here! Thanks


> Impossible to use blank strings as dialog titles
> ------------------------------------------------
>
>                 Key: CB-9449
>                 URL: https://issues.apache.org/jira/browse/CB-9449
>             Project: Apache Cordova
>          Issue Type: Bug
>          Components: Plugin Dialogs
>    Affects Versions: 3.5.0
>            Reporter: Ian Paterson
>            Priority: Minor
>              Labels: dialog, patch
>
> Currently there is no way to create a dialog in the Cordova Dialogs plugin 
> without a title. Providing an empty string as the title for any of {{alert}}, 
> {{confirm}}, or {{prompt}} results in a non-localized default title. This 
> makes it impossible to show message-only dialogs on platforms that support 
> such a thing, like iOS. Currently, all dialogs must have a title and 
> additionally prompts must have a message, whether they are provided by the 
> developer or forced by the plugin.
> h4. No workarounds
> There are no known workarounds. One that came to mind was passing a space 
> character {{navigator.notification.alert('message', null, ' ');}} but on iOS 
> this results in a blank space for the title at the top of the alert. Sending 
> an object that will evaluate to true but return a blank string when 
> stringified causes the app to crash {{navigator.notification.alert('message', 
> null, {toString: function() { return ''; }});}}
> h4. Solution
> Rather than testing whether {{title}} is falsy to set the default, test 
> whether it is a string, regardless of whether it is a falsy empty string. 
> h4. Breaking change?
> Requiring the title to be a string prevents numeric and other values from 
> being used, while previously they were passed through to the native plugin. 
> This is a _good thing_ because sending anything other than a string causes 
> the plugin to crash the app (at least on iOS), so despite being more 
> restrictive about the data type, I do not consider it a breaking change.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org
For additional commands, e-mail: issues-h...@cordova.apache.org

Reply via email to