[Interest] Qt at iOS: Crash on null QWindow pointer in QIOSInputContext::scrollToCursor

[Gustavsen Richard]

Currently the logic is so that if the current focus object in Qt supports text input (Qt::ImEnabled), then the platform plugin will inform iOS that cut/copy/paste actions are supported. iOS will then add extra items in the edit menu, extra buttons on the virtual keyboard (unless you apply your work-around), and send callbacks to Qt when pressing shortcut keys on a bluetooth keyboard. And currently I cannot think of any work-arounds you can do to hinder that (except remove input focus / close the keyboard before showing the menu).

I can investigate a bit if it's reasonable to dynamically inform iOS that we don't support e.g copy while opening an edit menu that has no items with QKeySequence::Copy included.

-Richard

________________________________________
Fra: Robert Iakobashvili <coroberti at gmail.com>
Sendt: 10. november 2015 11:58
Til: Gustavsen Richard; interest at qt-project.org
Emne: Re: [Interest] Qt at iOS: Crash on null QWindow pointer in QIOSInputContext::scrollToCursor

Dear Richard,
To get rid from Keyboard Shotcuts Bar with Cut/Copy/Paste is rather easy,
I'm using the below that works in 4.2 as well as in 5.5.1:

1. Disable predictive input in the window/text-field;
2. Pass the view/window/text-field as Wid (widget->winId()) to the
function below and disable two vectors/groups of UITextInputAssistantItem-s

void disable_iOS9_keyboard_shortcut_bar(void* window)
{
    if (SYSTEM_VERSION_GREATER_THAN_OR_EQUAL_TO(@"9.0")) {
        UIView* view = (UIView*)window; // You can also iterate thru
subviews if required.
        if ([view respondsToSelector:@selector(inputAssistantItem)]) {
            UITextInputAssistantItem *inputAssistantItem = [view
inputAssistantItem];
            inputAssistantItem.leadingBarButtonGroups = @[];
            inputAssistantItem.trailingBarButtonGroups = @[];
        }
    }
}

My question was about QPlatformMenu.
When doing the below:

QPlatformTheme *theme = QGuiApplicationPrivate::platformTheme();
QPlatformMenu *menu = theme->createPlatformMenu();
menu->setMenuType(QPlatformMenu::EditMenu);

QPlatformMenuItem *item = theme->createPlatformMenuItem();
item->setText(QLatin1String("MyCoolItem"));
menu->insertMenuItem(item, 0);

menu->showPopup(qApp->focusWindow(), QRect(100, 100, 0, 0), 0);


In Qt-5.4 it works properly and the menu seen has only "MyCoolItem"

In Qt-5.5 adds various standard Apple's standard items like
Cut, Copy, Paste, Speak, etc depending on area.

How to get rid of various standard Apple's menu items?

Thank you in advance.

Kind regards,
Robert


On Tue, Nov 10, 2015 at 12:26 PM, Gustavsen Richard
<Richard.Gustavsen at theqtcompany.com> wrote:
> Hi!
>
> If it's the cut/copy/paste actions you mean, it's problematic to remove them fully, since we don't really know if the application needs them or not. If we did, then support for e.g cmd-c on a bluetooth keyboard (or copy button on the virtual keyboard), would be removed as well.
>
> But after https://codereview.qt-project.org/#/c/124596/ we check if the application adds any actions with short-cut bindings to QKeySequence::StandardKey explicit (e.g QKeySequence::Copy). If so, we link the action directly to the corresponding native iOS menu item, including the button / shortcut on the keyboard.
>
> -Richard
>
> ________________________________________
> Fra: Robert Iakobashvili <coroberti at gmail.com>
> Sendt: 10. november 2015 09:43
> Til: Gustavsen Richard; interest at qt-project.org
> Emne: Re: [Interest] Qt at iOS: Crash on null QWindow pointer in QIOSInputContext::scrollToCursor
>
> Hi Richard,
>
> I was using 5.4.2, and I see that it was fixed for 5.5
>
> Unfortunately, in Qt-5.5  QPlatformMenu adds Apple's standard
> MenuItems prior to my custom item, so I cannot
> make my custom Editing Menu without Apple's standard;
> this is the reason to continue with 5.4
>
> Can we get rid from Apple's Menu Items in QPlatformMenu with Qt-5.5.1?
> Thanks!
>
> Regards,
> Robert
>
>
> On Tue, Nov 10, 2015 at 10:27 AM, Gustavsen Richard
> <Richard.Gustavsen at theqtcompany.com> wrote:
>> Which version on Qt are you using? It looks like this was fixed in 5.5:
>>
>> https://codereview.qt-project.org/#/c/109592/
>>
>>
>> -Richard
>>
>>
>> ________________________________
>> Fra: Interest <interest-bounces at qt-project.org> på vegne av Robert
>> Iakobashvili <coroberti at gmail.com>
>> Sendt: 10. november 2015 06:49
>> Til: interest at qt-project.org
>> Emne: [Interest] Qt at iOS: Crash on null QWindow pointer in
>> QIOSInputContext::scrollToCursor
>>
>> Gentlemen,
>> My app was crashing on a null QWindow pointer
>> from focusView() in QIOSInputContext::scrollToCursor
>>
>> Unfortunately, my attempt to create a reproducing example
>> failed; thus, a formal bug-report is not an option.
>>
>> The scenario is:
>> sending an email from a native popover over a Qt-widget app,
>> it was crashing on appearance of
>> Apple's Mail window.
>>
>> It could be work-arounded by checking the result of
>> focusView() call prior to using it and not assuming that
>> it for sure contains a valid QWindow:
>>
>> --- qiosinputcontext.mm.orig    2015-11-02 14:39:50.000000000 +0200
>> +++ qiosinputcontext.mm    2015-11-02 14:45:43.000000000 +0200
>> @@ -456,7 +456,10 @@
>>
>>      const int margin = 20;
>>      QRectF translatedCursorPos = qApp->inputMethod()->cursorRectangle();
>> -
>> translatedCursorPos.translate(focusView().qwindow->geometry().topLeft());
>> +    QWindow* qw = focusView().qwindow;
>> +    if (! qw)
>> +    return;
>> +    translatedCursorPos.translate(qw->geometry().topLeft());
>>
>>      qreal keyboardY = [rootView convertRect:m_keyboardState.keyboardEndRect
>> fromView:nil].origin.y;
>>      int statusBarY = qGuiApp->primaryScreen()->availableGeometry().y();
>>
>>
>> Hope, it helps to somebody.
>>
>> Take care,
>>
>> Regards,
>> Robert