Merge lp:~abreu-alexandre/unity-webapps-qml/handle-delayed-content-handler-creation into lp:unity-webapps-qml
Status: | Merged |
---|---|
Approved by: | Alberto Mardegan on 2016-04-28 |
Approved revision: | 158 |
Merged at revision: | 158 |
Proposed branch: | lp:~abreu-alexandre/unity-webapps-qml/handle-delayed-content-handler-creation |
Merge into: | lp:unity-webapps-qml |
Diff against target: |
150 lines (+98/-7) 1 file modified
src/Ubuntu/UnityWebApps/bindings/content-hub/backend/content-hub.js (+98/-7) |
To merge this branch: | bzr merge lp:~abreu-alexandre/unity-webapps-qml/handle-delayed-content-handler-creation |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Alberto Mardegan (community) | 2016-04-27 | Approve on 2016-04-28 | |
PS Jenkins bot (community) | continuous-integration | Approve on 2016-04-27 | |
Review via email:
|
Commit message
Handle delayed creation of content hub share/import/export handler that could miss transfer requests
Description of the change
Handle delayed creation of content hub share/import/export handler that could miss transfer requests
- 158. By Alexandre Abreu on 2016-04-27
-
tweak
PS Jenkins bot (ps-jenkins) wrote : | # |
PASSED: Continuous integration, rev:158
http://
Executed test runs:
SUCCESS: http://
SUCCESS: http://
Click here to trigger a rebuild:
http://
Alberto Mardegan (mardy) wrote : | # |
Can you clarify a bit how this works? If I look at this code, it seems that the _#action#
if (this._
if (this._
}
} else {
}
Alexandre Abreu (abreu-alexandre) wrote : | # |
> Can you clarify a bit how this works? If I look at this code, it seems that
> the _#action#
> into the array, so it seems that the first branch of the if() can never be
> executed:
>
> _exportRequested: function(transfer) {
> if (this._
> if (this._
> this._currentEx
> }
> this._currentEx
> } else {
> this._runHandle
> }
actually the rationale behind this is this one:
at the moment (and I am thinking about possibly revamping it), the content hub bits found in the JS bindings (used by html5 and webapps) are triggered by the JS. Meaning that as the application is being started, it is not until the webview has been triggered, and the content loaded that the JS code scripts are being injected to potentially add e.g. share handler for the content hub.
This delay creates a clear race and the content hub sharing transfer is currently being dropped since at the time that all the QML app tree is complete, there are no share requested signal handlers.
When the JS finally gets executed and binds some share handler callbacks the transfer requested has been popped.
So the idea is for those signals that can wake the app, always define handlers, and acknowledge the fact that only until we have one callback defined the app could have been woken up by a missed share/import/export request.
In this context, the expression this._exportReq
Alberto Mardegan (mardy) wrote : | # |
> So the idea is for those signals that can wake the app, always define
> handlers, and acknowledge the fact that only until we have one callback
> defined the app could have been woken up by a missed share/import/export
> request.
Now I got it, thanks! I missed the connections made in the setup() method; now it's clear.
PASSED: Continuous integration, rev:157 jenkins. qa.ubuntu. com/job/ unity-webapps- qml-ci/ 182/ jenkins. qa.ubuntu. com/job/ unity-webapps- qml-wily- amd64-ci/ 4 jenkins. qa.ubuntu. com/job/ unity-webapps- qml-wily- armhf-ci/ 4
http://
Executed test runs:
SUCCESS: http://
SUCCESS: http://
Click here to trigger a rebuild: s-jenkins. ubuntu- ci:8080/ job/unity- webapps- qml-ci/ 182/rebuild
http://