[webapp-container] Crash with open context menu

I can reliably reproduce the issue, and I confirm that it’s not present in the browser itself. However, in the browser, once the context menu is up, if I continue scrolling up/down with the finger, the page below the menu continues scrolling. It shouldn’t.

Um... I was testing latest rc-proposed and was shocked that this was still there. We should fix this before OTA8!

I meant we should fix this before OTA7 actually! Which is almost out.

It is quite likely that this bug has always been there in the webapp container, not a regression introduced in OTA7. In that regard it’s way too late for sneaking in a fix for OTA7 (QA is doing final validation on the image). I’m raising the importance of the bug so it can be fixed early in the OTA8 cycle.

This bug is not in OTA6. It is a regression.

And isn't final validation the point where stop-ship bugs can still be discovered? Else it's just rubber-stamping. Obviously, reasonable people can disagree that this is stop-ship. But the fact that we're in final validation doesn't mean that if the bug is bad enough, we can delay.

I think this bug is worse than you believe. It's easy to accidentally (or intentionally) trigger.

Consider you are looking at some webapp. And you put your finger on the screen, ready to scroll when you're done reading the paragraph. But you accidentally long-pressed a link in the article. Crash.

Or you very reasonably want to copy and paste a link. Crash. Copy and pasting links will not be possible in OTA7 if this ships.

Oh, it's still possible to copy and paste. You just can't scroll.

And it looks like jibel also doesn't believe this is stop-ship (he targeted this for OTA8).

Alright, I've been outvoted. I'll just be careful in webapps for a while. :)

The feature is new actually, ie context menu for webapps. So is not a regression. Worst case, we could disable it until a fix is made for OTA-8

Sorry I hadn’t realized this wasn’t present in OTA6, and thus it’s a regression. I acknowledge that’s a bad one, let’s fix this ASAP. As to whether this should be considered a stop-ship, I’ll leave it to QA/the product team.

David, I don't know what you mean. the context menu in webapps that says "Copy Link" was present in OTA6 and remains present unchanged in OTA7-proposed.

This is a regression.

The stack trace so far

#0 0x006f0062 in ?? ()
#1 0xadabb6b8 in base::Callback<void ()>::Run() const (this=0xbec5b9d0) at ../../../../third_party/chromium/src/base/callback.h:396
#2 base::debug::TaskAnnotator::RunTask (this=this@entry=0xb8286904, queue_function=<optimized out>, run_function=0xaf8854cc "MessageLoop::RunTask", pending_task=...)
    at ../../../../third_party/chromium/src/base/debug/task_annotator.cc:62
#3 0xadace73c in base::MessageLoop::RunTask (this=this@entry=0xb8286830, pending_task=...) at ../../../../third_party/chromium/src/base/message_loop/message_loop.cc:473
#4 0xadace8e6 in base::MessageLoop::DeferOrRunPendingTask (this=this@entry=0xb8286830, pending_task=...)
    at ../../../../third_party/chromium/src/base/message_loop/message_loop.cc:482
#5 0xadacebb8 in base::MessageLoop::DoWork (this=0xb8286830) at ../../../../third_party/chromium/src/base/message_loop/message_loop.cc:594
#6 0xada74c90 in oxide::qt::MessagePump::RunOneTask (this=0xb8743d98) at ../../../../qt/core/browser/oxide_qt_message_pump.cc:66
#7 0xb6100d46 in QObject::event(QEvent*) () from /usr/lib/arm-linux-gnueabihf/libQt5Core.so.5
#8 0xb6bc09fc in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib/arm-linux-gnueabihf/libQt5Widgets.so.5
#9 0xb6bc49aa in QApplication::notify(QObject*, QEvent*) () from /usr/lib/arm-linux-gnueabihf/libQt5Widgets.so.5
#10 0xb827ec40 in ?? ()

It is not specific to the container, a simple qml file such as:

import QtQuick 2.4
import QtQuick.Window 2.2
import com.canonical.Oxide 1.8 as Oxide
import Ubuntu.Web 0.2
import Ubuntu.Components 1.3

WebView {
    url: "http://ubuntu.com"

    contextualActions: ActionList {
        Action {
            text: i18n.tr("Copy link")
            objectName: "CopyLinkContextualAction"
            enabled: contextModel && contextModel.linkUrl.toString()
            onTriggered: Clipboard.push(["text/plain", contextModel.linkUrl.toString()])
        }
        Action {
            text: i18n.tr("Cut link")
            objectName: "CutContextualAction"
            enabled: contextModel && contextModel.isEditable &&
                     (contextModel.editFlags & Oxide.WebView.CutCapability)
        }
    }
}

triggers the issue caused I think by a double free memory corruption,

It seems to be the case for apps that dont provide a custom contextMenu component, and use the default one.

Adding oxide to the bug,

Added a branch for the container to "fix" the issue, but the core issue is still there, I'll debug oxide next,

As Alex pointed out in comment #11, the issue is not webapp-container specific, it potentially affects all QML apps embedding a WebView and defining contextual actions. The branch I linked fixes the issue everywhere. This is an even more minimal standalone reproducer:

import QtQuick 2.4
import Ubuntu.Components 1.3
import Ubuntu.Web 0.2
WebView {
    url: "http://ubuntu.com"
    contextualActions: ActionList {
        Action {
            text: i18n.tr("Copy link")
            enabled: contextModel && contextModel.linkUrl.toString()
            onTriggered: Clipboard.push(["text/plain", contextModel.linkUrl.toString()])
        }
    }
}

This bug was fixed in the package webbrowser-app - 0.23+15.10.20151022.1-0ubuntu1

---------------
webbrowser-app (0.23+15.10.20151022.1-0ubuntu1) wily; urgency=medium

  [ CI Train Bot ]
  * New rebuild forced.
  * Resync trunk.

  [ Olivier Tilloy ]
  * Add an exception to the generated apparmor profile to allow reading
    HERE’s TOS in the browser. (LP: #1507667)
  * Modify the generated apparmor profile to allow rw access to
    /dev/shm/.org.chromium.Chromium.* too. (LP: #1508054)
  * Update translation template.

  [ Ugo Riboni ]
  * Fix inability to drag the map to pan in Google maps, on desktop.
    (LP: #1503506)
  * Implement support for allowing or denying access to media input
    devices and for setting default media input devices. (LP: #1410996)
  * Refactor the BookmarksModel to be a singleton.

 -- Olivier Tilloy <email address hidden> Thu, 22 Oct 2015 15:07:49 +0000