Communication is a lost art

I recently reported an issue to one of my vendors regarding one of their web sites that they use as a vanity entry point to their service platform.

The initial report was:

When sending users to <website> via HTML form with a GET method, WebKit browsers (Chrome, Safari, and some Android browsers) append a "?" character (see WebKit bug 30103 (https://bugs.webkit.org/show_bug.cgi?id=30103) and Chrome bugs 108690, 121380 (http://code.google.com/p/chromium/issues/detail?id=108690,http://code.google.com/p/chromium/issues/detail?id=121380). 
This causes the browser to access "http://<website>/?" which redirects to http://<vendor website>/?" Note the trailing "?" on the <vendor> URL. The "?" is preserved, and appended to the password field, rending the URL invalid, and presenting the user with a login screen. 
Could you please update the redirect handling on <website> to not preserve the "?" character that WebKit is sending? Side note: any value sent after <website> is also preserved, triggering the same behavior. E.g.:<website>/foo redirects to <vendor website/foo ; while one can take the stance "don't do that", it would be a better user experience to not preserve any path data if it is going to cause errors like this.

I reported the issue, the cause of the issue, the symptoms, the URLs involved, and a resolution path.

Could you provide the screenshots of the issue you reported until  the "?" is preserved, and appended to the password field, rending the URL invalid, and presenting the user with a login screen. This will help in forwarding this issue to the concerned department for further investigation. 

Screenshots?

Really?

To address an issue with how a vanity entry web site mishandles any extra data passed in the URL you want screenshots?

Really?!?

OK, fine, I'll take some screen captures of exactly what I stated and send them.

The website URL

The vendor URL

See?  Start at http://<website>/? and you get redirected to http://<vendorsite>/login..../?

The "?" abides.

Thank you for your email and also for the screenshots. I have forwarded this issue to the appropriate department for further investigation. I will contact you as soon as there is any information regarding this.

I have passed the gauntlet, there is hope that this issue will be fixed!

I received an update from the concerned department regarding the issue with  sending users to <website> via HTML form with a GET method, WebKit browsers (Chrome, Safari, and some Android browsers) append a "?" character. The concerned department has requested for the exact sequence of steps to duplicate this issue. Could you provide the same.

Umm.  HTML form....GET method...this is not looking good.

Load this basic HTML form in a Chrome browser:
<form method="get" action="<website>" >
<input type="submit"/>
</form>
Click the submit button.  Chrome will append a "?" character to the URL, and the <vendor> login error page will be generated. 

I can appreciate the need for a good test case, but this one seemed pretty straightforward...

Thank you for your email and for the additional information too. I have forwarded this to the appropriate department for further review. I will keep you updated as I receive any information in this direction.

My enthusiasm has been diminished, but we'll see if that's the missing part the vendor needed to resolve this.

I received the following update from the concerned department regarding " WebKit browsers (Chrome, Safari, and some Android browsers) appending a "?" character. The update is that 'this appears to be an issue with webkit itself and will have to be fixed by google or apple in the webkit engine. Unfortunately we do not think there is anything we can do on the <vendor> side since this is not specific to <vendor service>. This would happen with any URL.

Sigh. I am not asking them to fix WebKit; I am asking them to fix the way their vanity entry website handles redirecting users into their service platform website to address a very specific browser issue.

I can't help but think of old school burlesque/vaudeville comedy routines (Who's on First, etc.), and the memorable scene from Pulp Fiction between Jules Winnfield (Samuel L. Jackson) and Brett (Frank Whaley).

Apparently the "concerned department" does not grasp the concept of the Robustness Principle.  Funny thing is, the other vanity entry web sites for this vendor work just fine, it's only this one entry point that is broken.

Get the popcorn, kids! This one could drag out for a while.

Logfile spelunking: /cache/ trash

I regularly make time to run some ad-hoc reports on the log files from our web servers to look for strange and unusual things.  Thanks to the Interwebs, there are never a shortage of either to be found.

Each trip through the log files, I try to isolate at least one error or error message and find the root cause. Once I have that, I then look for ways to remedy or work around the issue.  Sometimes I get lucky and it's something that I can actually put a fix in for, but most times I'm left with a more questions and fewer answers.

The symptom of today's journey of exploration was the addition of "/cache/<hex string>" to random URLs on the site that has been going on for some time now.  It has been affecting Chrome users, and across several Chrome versions.

I had initially be scouring the JavaScript on the site to see if one of the 3rd party libraries had gone off the deep end and had a bug that only Chrome users hit, with no success.  A few months ago, I went down the path of bad caching/acceleration software that was using a scheme like this to ... well, your guess is as good as mine.

Today, though, I got lucky: I found an answer.

What I was able to track down today is a report of similar problems on other sites that lead me to a Chrome bug report, as well as a one of many self-help malware remedy pages.  It seems that people have installed an extension called "Browser Companion Helper" that sounds like it is anything but what the name would suggest.

Since knowing is half the battle, now the next trick is to figure what to do with this new information.

There does not appear to already be a way to detect the plugin and alert the user directly.  Without infecting one of my systems with that malware, I can't figure out if there is a way to redirect the user to a removal page to clean up their system, as sometimes the erroneous URL is requested before a legitimate one, other times after.

It would be nice if Google could blacklist plugins like this and prevent the extension from running in a future release of Chrome.  It looks like there was some work done mid-2012 in the extension blacklist corner of Chrome, but it is unclear what Google's policy is for shipping default blacklists in cases like this.

So I'm not sure just how much I might be able to do to remedy the real root cause and enable the user to get the malware off their system.  In the mean time, I now know what causes these requests, and I can safely ignore them as a client-side issue, not something that the JavaScript on our pages is doing wrong.

Tarnished Chrome

I used to think very highly of Google's Chrome browser.  It developed a reputation for being a lightning fast, standards compliant browser, and it was one of the first -- if not the first -- browsers to auto-upgrade users to the latest release.

But recently, I have been finding myself more frustrated with Chrome than Internet Exploder Explorer.

Among the issues I've run into recently:

• If you have a HTML form with a GET action, but no input elements, the browser appends a "?" to the action URL.  There are a few different bugs logged with Chrome and with WebKit on this issue.  Many web sites will accept this extra character without complaint, but some sites with naive redirect rules get rather cranky when this happens.
• Chrome's handling of popup windows makes my brain hurt.  I thought the purpose of popup blockers was to not load content in the first place.  Because of how they handle popups, JavaScript code cannot determine when a popup succeeded or failed, because it always succeeds, even when it fails.  Ouch!
• Even Chrome Frame is not immune.  There appears to be a food fight between Chrome Frame and Internet Explorer over cookie handling in general, and there may be some corner cases in AJAX handling where cookies are not preserved.
• There is some utterly bizarre issue on Chrome 11 that ships with the B&N Nook that causes AJAX-driven actions to pause for 20 seconds before running during on the 2nd execution.  Across 34 variations of desktop browser and OS and 10 different mobile flavors, no other browser exhibits that behavior.  That's going to be a fun one to track down.

Don't get me wrong, Chrome is still a decent browser.  So far it gives me much less trouble than Internet Explorer, but its stock definitely fell a few points after having to work around these issues.