[browser] Add support for Confirm dialogs

Bug #1169758 reported by Adnane Belmadiaf
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
webbrowser-app
Fix Released
High
Adnane Belmadiaf
webbrowser-app (Ubuntu)
Fix Released
High
Unassigned

Bug Description

Related branches

Revision history for this message
Olivier Tilloy (osomon) wrote :

The 'experimental' attached property of the webview allows setting the 'confirmDialog' property to a custom QML component. By default the value of this property is null, meaning confirm dialogs are not handled.

Changed in touch-preview-images:
status: New → Confirmed
affects: touch-preview-images → webbrowser-app
Adnane Belmadiaf (daker)
Changed in webbrowser-app:
assignee: nobody → Adnane Belmadiaf (daker)
Bill Filler (bfiller)
Changed in webbrowser-app:
importance: Undecided → High
Changed in webbrowser-app (Ubuntu):
status: New → Confirmed
importance: Undecided → High
Adnane Belmadiaf (daker)
Changed in webbrowser-app:
status: Confirmed → In Progress
Revision history for this message
PS Jenkins bot (ps-jenkins) wrote :

Fix committed into lp:webbrowser-app at revision 335, scheduled for release in webbrowser-app, milestone ubuntu-13.04-month-5

Changed in webbrowser-app:
status: In Progress → Fix Committed
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package webbrowser-app - 0.22+13.10.20130926.1-0ubuntu1

---------------
webbrowser-app (0.22+13.10.20130926.1-0ubuntu1) saucy; urgency=low

  [ daker ]
  * Added support for confirm dialogs. (LP: #1169758)
  * Added support for Prompt dialogs. (LP: #1169759)

  [ Adnane Belmadiaf ]
  * Added support for confirm dialogs. (LP: #1169758)
  * Added support for Prompt dialogs. (LP: #1169759)

  [ Alexandre Abreu ]
  * The application name is being set from the APP_ID during the init
    phase of the webbrowser app but it is later being overwritten
    because of the applicationName property in the browser MainView. One
    option could be to get rid of the applicationName property update
    altogether but it is being used by the MainView to update the domain
    for the i18n plugin which is itself flawed in a way since it does
    not fallback on the Qtcore::applicationName but requires the
    applicationName property of a MainView to be set explicitely. . (LP:
    #1229942)

  [ Olivier Tilloy ]
  * When the activity view cannot be found, return None instead of
    raising an exception, as that’s what tests expect.
  * Contextual menus with specific actions for links and images when
    they are long-pressed.
  * Fix dependencies alignment in debian/control.
  * Adjust margins in the chrome to be consistent with the default
    toolbar. (LP: #1223946)
  * New assets and visual tweaks for the expanded activity view. (LP:
    #1223952)
  * Updated translation template.
  * Go directly to the entry instead of expanding the timeline view when
    there is only one entry for a given domain. This change has been
    requested by design.
  * Very basic support for ini-style read-only settings. This is a
    temporary solution until Settings support lands in the SDK. At the
    moment, only the default homepage can be customized. To change the
    default homepage, one can write the following line to
    ~/.config/webbrowser-app/settings.conf:     homepage =
    http://example.org.
  * Match domains for overriding the UA string by starting from the full
    domain name, and iterating down to the TLD. This ensures that if
    there is an override rule for "b.a.c", it will get precedence over
    another existing rule for "a.c".

  [ Ubuntu daily release ]
  * Automatic snapshot from revision 346
 -- Ubuntu daily release <email address hidden> Thu, 26 Sep 2013 08:47:31 +0000

Changed in webbrowser-app (Ubuntu):
status: Confirmed → Fix Released
Olivier Tilloy (osomon)
Changed in webbrowser-app:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers