gmail webapp crashes when attaching a contact to a new message

Bug #1466892 reported by Jean-Baptiste Lallement
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Oxide
New
Undecided
Unassigned
webbrowser-app (Ubuntu)
Fix Released
Undecided
Unassigned

Bug Description

Only reproduced on Arale

current build number: 31
device name: arale
channel: ubuntu-touch/rc-proposed/meizu.en
last update: 2015-06-19 14:56:08
version version: 31
version ubuntu: 20150619.1
version device: 20150608-6e66f3c
version custom: 20150602-731-5-32

webapp-container 0.23+15.04.20150602-0ubuntu1

Test Case:
1. Add a Google account and ensure there are contacts in the address book
2. Open gmail
3. Create a new message
4. Tap on add an attachment
5. Select a contact and confirm

Expected Result
The contact is added

Actual Result
GMail crashes

Crash file attached.

Related branches

Revision history for this message
Jean-Baptiste Lallement (jibel) wrote :
Revision history for this message
Olivier Tilloy (osomon) wrote :

Here is the backtrace extracted from the crash file:

#0 oxide::FilePicker::Done (this=this@entry=0xb8ecf030, files=std::vector of length 1, capacity 1 = {...},
    permissions=content::FileChooserParams::OpenMultiple) at ../../../../shared/browser/oxide_file_picker.cc:50
#1 0xaccfcdc6 in oxide::qt::FilePicker::done (this=0xb8ecf030, files=...,
    mode=oxide::qt::FilePickerProxy::OpenMultiple) at ../../../../qt/core/browser/oxide_qt_file_picker.cc:134
#2 0xacabf2fa in oxide::qquick::FilePickerContext::accept(QVariant const&) const ()
   from /usr/lib/arm-linux-gnueabihf/libOxideQtQuick.so.0
#3 0xacabf902 in oxide::qquick::FilePickerContext::qt_static_metacall(QObject*, QMetaObject::Call, int, void**) ()
   from /usr/lib/arm-linux-gnueabihf/libOxideQtQuick.so.0
#4 0xacabf9e0 in oxide::qquick::FilePickerContext::qt_metacall(QMetaObject::Call, int, void**) ()
   from /usr/lib/arm-linux-gnueabihf/libOxideQtQuick.so.0
#5 0xb63b5040 in ?? () from /usr/lib/arm-linux-gnueabihf/libQt5Qml.so.5
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

The issue is there:

  void FilePicker::Done(const std::vector<content::FileChooserFileInfo>& files,
                        content::FileChooserParams::Mode permissions) {
    render_view_host_->FilesSelectedInChooser(files, permissions);

where render_view_host_ is null.

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

This looks like bug #1441777, however it was supposedly fixed in oxide 1.7 (and backported to 1.6).

Revision history for this message
Ken VanDine (ken-vandine) wrote :

I marked this as confirmed because others have reproduced it. I can't reproduce it myself, which is a bit confusing. @michael-sheldon can reproduce it reliably.

Changed in webbrowser-app (Ubuntu):
status: New → Confirmed
Revision history for this message
Alexandre Abreu (abreu-alexandre) wrote :

I am not able to reproduce it on image 58. Could you try again?

Changed in webbrowser-app (Ubuntu):
status: Confirmed → Incomplete
Revision history for this message
Jean-Baptiste Lallement (jibel) wrote :

I cannot reproduce on latest rc-proposed either. I'm closing this report and will reopen if it happens again.

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

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.