flow - Dave's Blog

The scrollbars in UWP WebView and in Edge have different default behavior leading to many emails to my team. (Everything I talk about here is for the EdgeHtml based WebView and Edge browser and does not apply to the Chromium based Edge browser and WebView2).

There is a Edge only -ms-overflow-style CSS property that controls scroll behavior. We have a different default for this in the WebView as compared to the Edge browser. If you want the appearance of the scrollbar in the WebView to match the browser then you must explicitly set that CSS property. The Edge browser default is scrollbar which gives us a Windows desktop styled non-auto-hiding scrollbar. The WebView default is -ms-autohiding-scrollbar which gives a sort of compromise between desktop and UWP app scrollbar behavior. In this configuration it is auto-hiding. When used with the mouse you'll get Windows desktop styled scrollbars and when used with touch you'll get the UWP styled scrollbars.

Since WebViews are intended to be used in apps this style is the default in order to better match the app's scrollbars. However this difference between the browser and WebView has led to confusion.

Here’s an -ms-overflow-style JSFiddle showing the difference between the two styles. Try it in the Edge browser and in WebView. An easy way to try it in the Edge WebView is using the JavaScript Browser.

There's a lot of name reuse in HTTP compression so I've made the following to help myself keep it straight.

HTTP Content Coding Token	gzip	deflate	compress
	An encoding format produced by the file compression program "gzip" (GNU zip)	The "zlib" format as described in RFC 1950.	The encoding format produced by the common UNIX file compression program "compress".
Data Format	GZIP file format	ZLIB Compressed Data Format	The compress program's file format
Compression Method	Deflate compression method		LZW
	Deflate consists of LZ77 and Huffman coding

Compress doesn't seem to be supported by popular current browsers, possibly due to its past with patents.

Deflate isn't done correctly all the time. Some servers would send the deflate data format instead of the zlib data format and at least some versions of Internet Explorer expect deflate data format instead of zlib data format.

The following code compiled just fine but did not at all act in the manner I expected:

BOOL CheckForThing(__in CObj *pObj, __in IFigMgr* pFigMgr, __in_opt LPCWSTR url)
{
    BOOL fCheck = FALSE;
    if (SubCheck(pObj))
    {
        ...

I’m calling SubCheck which looks like:

bool SubCheck(const CObj& obj);

Did you spot the bug? As you can see I should be passing in *pObj not pObj since the method takes a const CObj& not a CObj*. But then why does it compile?

It works because CObj has a constructor with all but one param with default values and CObj is derived from IUnknown:

CObj(__in_opt IUnknown * pUnkOuter, __in_opt LPCWSTR pszUrl = NULL);

Accordingly C++ uses this constructor as an implicit conversion operator. So instead of passing in my CObj, I end up creating a new CObj on the stack passing in the CObj I wanted as the outer object which has a number of issues.

The lesson is unless you really want this behavior, don't make constructors with all but 1 or 0 default parameters. If you need to do that consider using the 'explicit' keyword on the constructor.

More info about forcing single argument constructors to be explicit is available on stack overflow.

The following code works fine. I have a ccomptr named resolvedUri and I want to update its hostname so I do the following:

        CreateIUriBuilder(resolvedUri, 0, 0, &builder);
        builder->SetHost(host);
        builder->CreateUri(0xFFFFFFFF, 0, 0, &resolvedUri);

But the following similar looking code has a bug:

    ResolveHost(resolvedUri, &resolvedUri);

The issue is that doing &resolvedUri gets the address of the pointer but also clears out the pointer due to the definition of my smart pointer class:

    operator T**()  
    {  
        T *ptrValue = mPtrValue;
        mPtrValue->Release();
        mPtrValue = NULL;
        return &ptrValue;
    }

In C++ there’s no guarantee about the order in which parameters for a function or method are evaluated. In the case above, &resolvedUri clears out the ccomptr before evaluating resolvedUri.Get() and so ResolveHostAlias gets a nullptr.

An interesting and related thread on stack overflow on undefined behavior in C++.