That was what I wanted to avoid :-) ie. when accessing, I wanted to
check if it had been set (there is a good chance it has) and if not do
a sync call.
The other option would be if there is a way to send the orientation to
the JS from within the *Instance ctor, as I suppose the ctor will have
to be executed before you actually process the screen.orientation
call.
Kenneth
On Wed, Jan 15, 2014 at 5:53 PM, Jesus Sanchez-Palencia
<forge...@gmail.com> wrote:
> Hi,
>
> I'm replying, but please keep in mind I haven't read the W3C API spec
> for Screen Orientation.
>
> On Wed, Jan 15, 2014 at 2:17 PM, Kenneth Rohde Christiansen
> <kenneth.christian...@gmail.com> wrote:
>> Hi there,
>>
>> The orientation extension has the issues that the values might not be
>> set by the extension before they are accessed. I discussed this with
>> Jeez and he suggested that we just always load the extension.
>
>
> So, I had a closer look at this extension. I have double checked with
> vinicius as well, and we are now convinced that always loading the
> extension wouldn't fix the issue. In summary, what you want to make
> sure with this extension is that calling:
>
> "var my_orientation = screen.orientation;"
>
> will always provide a valid and correct value. I had a look at the way
> the native side of this extension is implemented nowadays and I could
> see the flow for this property is:
>
> 1- ScreenOrientationInstance ctor calls
> ScreenOrientationInstance::OnOrientationChanged passing the current
> orientation, by posting this task to the UI thread;
> 2- OnOrientationChanged calls PostMessageToJS passing the orientation value;
> 3- screen.orientation gets its correct value on the JS side.
>
> There is a race condition there, since currently screen.orientation is
> an entry_point of this extension. Even if we had loaded this
> extension upfront, we wouldn't be able to guarantee that this flow
> would have finished in time for the *FIRST* screen.orientation access.
> Yes, it most likely would have finished in time, but we can't be 100%
> sure.
>
> The only idea we had was to change a bit how the JS shim is
> implemented. I would do something like:
>
> "
> var orientationValue = "";
>
> Object.defineProperty(window.screen, "orientation", {
> configurable: false,
> enumerable: true,
> get: function() {
> if (orientationValue === "") {
> var msg = JSON.stringify({'cmd' : 'GetScreenOrientation'});
> var result = extension.internal.sendSyncMessage(msg);
> orientationValue = JSON.parse(result);
> }
>
> return orientationValue;
> },
> });
> "
>
> Putting in words, I would add a sync message to the initial
> screen.orientation read. Note that it is not guaranteed this sync
> message will always be used.
>
>
> I hope that helps, but it would be nice to hear ideas from others.
> Perhaps Thiago has faced similar situations during his SysApps' work?
>
>
> Cheers,
> jesus
>
>
>
>>
>> Thus we could load the extension possible just after creating the
>> document (DOM readyState == loading) and we shouldn't have any
>> problems.
>>
>> Any way to do this or to bypass the lazy loading? When exactly was the
>> extensions loaded before without lazy loading?
>>
>> Cheers
>> Kenneth
>>
>> --
>> Kenneth Rohde Christiansen
>> Web Platform Architect, Intel Corporation.
>> Phone +45 4294 9458 ﹆﹆﹆
>> _______________________________________________
>> Crosswalk-dev mailing list
>> Crosswalk-dev@lists.crosswalk-project.org
>> https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev
--
Kenneth Rohde Christiansen
Web Platform Architect, Intel Corporation.
Phone +45 4294 9458 ﹆﹆﹆
_______________________________________________
Crosswalk-dev mailing list
Crosswalk-dev@lists.crosswalk-project.org
https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev
