Closed Bug 794983 Opened 7 years ago Closed 7 years ago

Backport winrt widget's component extensions to vs2010

Categories

(Core :: Widget: Win32, defect)

x86_64
Windows 8.1
defect
Not set

Tracking

()

RESOLVED FIXED

People

(Reporter: jimm, Assigned: jimm)

References

Details

(Whiteboard: [metro-mvp][LOE:-][leave-open][completed-elm])

Attachments

(3 files, 4 obsolete files)

Biting a very painful bullet.

A nice place to start on this might be to try and unwrap FrameworkView so that we can get better crash stacks from elm nightlies.
Blocks: 793428
Whiteboard: metro-beta → [metro-mvp]
Attached patch wip (obsolete) — Splinter Review
Assignee: nobody → jmathies
Whiteboard: [metro-mvp] → [metro-mvp][LOE:-]
Attached patch wip (obsolete) — Splinter Review
Only the file picker left.
Attachment #675113 - Attachment is obsolete: true
Attached patch patch v.1 (obsolete) — Splinter Review
Attachment #675526 - Attachment is obsolete: true
Blocks: 805553
Attached patch configure patchSplinter Review
Attachment #676237 - Attachment is obsolete: true
Attached patch widget patch v.1Splinter Review
Comment on attachment 676537 [details] [diff] [review]
configure patch

Removing this check from mc/elm since we'll be building with both sdks.
Attachment #676537 - Flags: review?(ehsan)
Comment on attachment 676538 [details] [diff] [review]
widget patch v.1

I can split this up by file if need be. It's not that bad really on its own.
Attachment #676538 - Flags: review?(netzen)
A few hints on activation:

For classes that have a default constructor, you can use the generic activation factory call. ActivateGenericInstance in MetroUtils can retrieve this.

For classes with custom constructors, the class should provide its own class factory which you have to retrieve manually using GetActivationFactory. For example, ISecondaryTileFactory creates a ISecondaryTile through a CreateWithId call on the factory interface.

For statics, the activation factory will expose these. You still call GetActivationFactory and pass in the statics interface pointer.
Attachment #676537 - Flags: review?(ehsan) → review+
Comment on attachment 676538 [details] [diff] [review]
widget patch v.1

Review of attachment 676538 [details] [diff] [review]:
-----------------------------------------------------------------

I know you're still fixing a problem with touch input.

I only did a fast pass on this, I think it's better to land it sooner than later and fix things over time.
Maybe some of the UUIDs of the changed IDLs should be updated.

::: browser/metro/base/content/browser-ui.js
@@ +142,5 @@
>        }
>  
>        try {
> +        MetroUtils.addSettingsPanelEntry("prefs-container", "Preferences");
> +        MetroUtils.addSettingsPanelEntry("downloads-container", "Downloads");

glad you moved this over to , we have to fix the strings so they are localized later.

::: widget/windows/Makefile.in
@@ -122,5 @@
>  include $(topsrcdir)/config/rules.mk
>  
> -ifdef MOZ_METRO
> -CXXFLAGS += -ZW
> -endif

Yay! :)

::: widget/windows/winrt/FrameworkView.cpp
@@ +53,5 @@
>  {
>    mPainting = false;
> +  memset(&sKeyboardRect, 0, sizeof(Rect));
> +  sSettingsMap = new nsDataHashtableMT<nsStringHashKey, nsString>();
> +  if (sSettingsMap) {

Isn't this allocation infallible?
https://developer.mozilla.org/en-US/docs/Infallible_memory_allocation

::: widget/windows/winrt/MetroContracts.cpp
@@ +310,5 @@
>    if (NS_SUCCEEDED(rv)) {
>      // This doesn't seem to be used by the apps I share to
> +    //aArg->Request->Data->Properties->ApplicationName = L"Firefox";
> +    //aArg->Request->Data->Properties->Title = ref new Platform::String(title.BeginReading());
> +    //aArg->Request->Data->SetUri(ref new Uri(ref new Platform::String(url.BeginReading())));

This needs to be converted still.

::: widget/windows/winrt/MetroUtils.cpp
@@ +185,5 @@
> +  ComPtr<IUriRuntimeClassFactory> uriFactory;
> +  hr = GetActivationFactory(HStringReference(RuntimeClass_Windows_Foundation_Uri).Get(), &uriFactory);
> +  AssertRetHRESULT(hr, hr);
> +  ComPtr<IUriRuntimeClass> uri;
> +  AssertRetHRESULT(hr = uriFactory->CreateUri(aUriStr, &aUriOut), hr);

Add:
return S_OK;

@@ +195,5 @@
> +  ComPtr<IUriRuntimeClassFactory> uriFactory;
> +  hr = GetActivationFactory(HStringReference(RuntimeClass_Windows_Foundation_Uri).Get(), &uriFactory);
> +  AssertRetHRESULT(hr, hr);
> +  ComPtr<IUriRuntimeClass> uri;
> +  AssertRetHRESULT(hr = uriFactory->CreateUri(aHString.Get(), &aUriOut), hr);

Add:
return S_OK;

@@ +220,5 @@
> +    appViewStatics.GetAddressOf());
> +  AssertRetHRESULT(hr, hr);
> +  boolean success = false;
> +  hr = appViewStatics->TryUnsnap(&success);
> +  return hr;

So I think you should have a boolean out parameter here.
I think in some cases this call can fail with HRESULT.
But in some cases the call can succeed, but success will hold false, indicating that in the current state you can't unsnap.
Attachment #676538 - Flags: review?(netzen) → review+
Attached patch widget patch (landed) (obsolete) — Splinter Review
Attachment #676991 - Attachment is obsolete: true
configure patch on inbound:
https://hg.mozilla.org/integration/mozilla-inbound/rev/b10caa15e653

elm:
https://hg.mozilla.org/projects/elm/rev/4b8bc61b9f32
https://hg.mozilla.org/projects/elm/rev/4db5dd0f8866
Whiteboard: [metro-mvp][LOE:-] → metro-mvp, LOE:-, leave-open, completed-elm
No longer blocks: enable-8.0sdk
Blocks: 806799
No longer blocks: 805553
No longer blocks: enable-8.0sdk
Whiteboard: metro-mvp, LOE:-, leave-open, completed-elm → [metro-mvp][LOE:-][leave-open][completed-elm]
Depends on: 829183
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
OS: Windows 8 Metro → Windows 8.1
You need to log in before you can comment on or make changes to this bug.