[TIMOB-24763] iOS: Ti.App.fireEvent not working for webviews in scrollviews
| GitHub Issue | n/a |
|---|---|
| Type | Bug |
| Priority | Critical |
| Status | Closed |
| Resolution | Not Our Bug |
| Resolution Date | 2017-06-05T10:46:20.000+0000 |
| Affected Version/s | Release 6.1.0 |
| Fix Version/s | n/a |
| Components | iOS |
| Labels | fireevent, ios, merge-6.1.1, regression, webview |
| Reporter | Anthony Chung |
| Assignee | Vijay Singh |
| Created | 2017-06-02T10:42:53.000+0000 |
| Updated | 2017-06-05T23:09:00.000+0000 |
Description
Please test Ti.App.fireEvent not working for webviews in scrollviews.
with sdk 6.1.1.v20170531135549
Scenario:
Multiple webviews in a parent scrollview.
Set with willHandleTouches:false
contains html with a hrefs with:
onclick="Ti.App.fireEvent...
The parent controller has
Ti.App.addEventListener(eventname,webCallback);
SDK:
6.1.1.v20170531135549
*EDIT by [~hansknoechel]*: Changing the
Affected Version to 6.1.0, since 6.1.1 is from the same branch and therefore it's easier to group it with other 6.1.0 related tickets.
Please provide a full test-case before, so our support team can validate it, thx!
I've ran tests locally and it looks like it has to do with the __ti_injection not happening on my production app. But on the test app, __ti_injection works. So the fireEvents are working. Do you have any idea why __ti_injection would not be working in a production app?
Hi Hans, Close this issue! Found the problem - local production code and not appc issue. Explanation... __ti_injection was not created, therefore Ti.App.fireEvent would work because the webview html was a html snippet and not a fully formed html with wrapping html and body tags. It looks like the injection only happens for full html and not just snippets. After wrapping the html snippet with tags, the ti_injection is now showing up in Safari:Develop: web inspector in the production app.
<script id='__ti_injection'>window.Titanium={};window.Ti=Titanium...As per Anthony Chung's comment in the ticket that problem is not from SDK side, closing the issue.
Closing ticket as this has been found to not be our bug.