178542 - ActiveX plugin work

Status: RESOLVED FIXED

(Core Graveyard :: Embedding: ActiveX Wrapper, defect)

Description

[Adam Lock]

Placeholder for the latest plugin work so far.

Comment 1

[Adam Lock]

Attachment: Patch of all plugin changes

This is a diff -u of the plugin/control changes in my tree. Please feel free to
review / inspect this and point out any issues you see.

Changes roughly in the order they appear:

* ControlSite.cpp/h
    * Test for clsid in registry during safe for scripting checks
      to return a more meaningful REGDB_E_CLASSNOTREG error
    * Add test for IObjectSafety when creating new object
    * Support for downloading and installing cab files,
      incl. parsing the #version=a,b,c,d stuff in the codebase url (bug 173108)

    * Support for new PropertyList class
    * Implement IOleControlSite::GetContainer to support changed 
      behaviour in WMP9 for obtaining the IHTMLDocument2 iface.
    * New SetContainer method

MozillaBrowser.cpp (not really plugin)
    * Support for new PropertyList class

PropertyBag.cpp
    * Support for new PropertyList class

PropertyList.h
    * Rewrite PropertyList class to remove dependency on stl &
      cleanup code.

LegacyPlugin.cpp
    * Add const switches to the top to control behaviour such as whether
      to download controls, host unsafe for scripting controls etc.
    * Implemented IBindStatusCallback object to display control
      download progress, provide a window handle for the trust dialog.
    * Add support for MS black list, plus our own whitelist/blacklist
    * Support for new PropertyList class
    * Add support to downloading and installing controls from codebase

Makefile.in
    * Remove references to WMP

XPCBrowser.cpp
XPCDocument.cpp
    * Clean up skeleton DOM and move calls to NPN_ methods into the Init()
      methods to ensure they're called by the main thread. I discovered
      WMP would call things like get_URL on random threads, and NPN_ functions
      are not happy at all to be called in this way.
    * IEDocument class implements IOleContainer to keep WMP 9 happy. The old
      WMP 7 used to get the IHTMLDocument2 from the IServiceProvider, but 
      WMP 9 calls IOleControlSite::GetContainer to get the container object
      and then QIs that.

XPConnect.cpp
    * Fire events to script handlers (bug 174404)
    * Remove small amounts of WMP crud
    * Add armour to scriptable peer code to prevent handing out
      scriptable objects when the control is still downloading or
      non-existant.

Comment 2

[Adam Lock]

Can I get an r/sr on this please?

Comment 3

[rpotts (gone)]

comments:

* the hard-coded string in CInstallControlProgress::OnProgress(...) should
probably live in a resource for localization...

* I'm a little afraid that a new event eueue is not being pushed before we enter
this loop...  My main fear is that since we are deep inside of layout, there may
be pending PLEvents which could get processed 'out of order'.  I'd check with
danm and jst to make sure this fear is not grounded :-)

+                MSG msg;
+                // Process pending messages
+                while (::PeekMessage(&msg, NULL, 0, 0, PM_NOREMOVE))
+                {
+                    if (!::GetMessage(&msg, NULL, 0, 0))
+                    {
+                        pProgress->mBindingInProgress = FALSE;
+                        break;
+                    }
+                    ::TranslateMessage(&msg);
+                    ::DispatchMessage(&msg);
+                }
+  


* It looks like there are some other hard-coded strings used in the UI that
should probably get resourced...

Other than that it looks good...
sr=[e-mail]

Comment 4

[Peter Lubczynski]

r=peterl

Comment 5

[Adam Lock]

The modal loop, is basically for when CControlSite::Create is called without
supplying a IBindStatusCallback. In such circumstances, the method spins around
in this loop until the control downloads and installs and can be created by the
time Create returns. CControlSite is a generic class which is why I added it.

For the plugin, we do provide an IBindStatusCallback so this code won't be
invoked. However, for the duration of the control download, we're at the mercy
of the main message pump in NS which may or may not be happy with freezing the
layout for so long and other fun issues. We'll have to wait and see...

There are a couple of hardcoded strings in the download progress meter. I'll try
and address them in due course.

Comment 6

[Adam Lock]

Patch is checked in, I'll leave this bug open to tie up loose ends

Comment 7

[Adam Lock]

Marking fixed, new issues will be covered by new bugs