For Want of a Scrollbar

The start of an adventure usually starts when I tweet an annoyance:

Who has two thumbs and regularly disables Sharepoint’s overflow: hidden CSS to re-enable the scrollbar? Me…

A coworker asked a good question, which is, “Any easy/lazy way to make it automatic-like?”

My response was a Greasemonkey script should do the trick. Okay, so, how to make it happen?

Pretty sure like me, my coworker uses Chrome. This is good, because in 2009 Chrome acquired native Greasemonkey script support. They are treated as Extensions. I like this because there is one place to look for the scripts rather than a separate queue like I am familiar in Firefox’s Greasemonkey plug-in.

So I found some pages on writing Greasemonkey scripts. What I wanted to do looked easy enough. Which, of course, meant I spent a few hours stumbling around the Internet confused why it did not work. In the end, I wrote this <filename>.users.js did the trick:

// ==UserScript==
// @name Sharepoint Scrollbar Fix
// @namespace
// @description Removes the overflow:hidden which is buggy in WebKit browsers
// @include*
// ==/UserScript== = “scroll”;

From my research WebKit browsers have an issue with overflow:hidden going back years. Chrome and Safari are WebKit browsers. (Guess I could have saved myself time just using Mozilla.) Using either overflow:scroll, overflow:auto, or even removing overflow brings out a second usable scrollbar.

Probably GM_addStyle is a better approach, but this one worked first.

Protocols matter. Most of the time I spent confused was solved by having http in the @include address when the Sharepoint site uses https.

Testing it was interesting as Google does not allow just downloading from anywhere on the Internet. So uploading it to my web site was not a good way to get it into the browser. Just open up Extensions and drag and drop the file in there. It prompts to make sure you are. In the end, it is much more efficient that way.

Conclusion: Pretty easy to create and test. Very lazy fix. The information online about making one is not great.

Any coworkers who want to use it, I added it to the Content area on my site.

Just Get Rid of Java

Apparently there are security flaws in the current version of Java allowing the installation of malicious software through web browsers unknown to the user. The known attacks using this flaw work on Windows, OSX, and Linux. According to Reuters:

Java was responsible for 50 percent of all cyber attacks last year in which hackers broke into computers by exploiting software bugs, according to Kaspersky. That was followed by Adobe Reader, which was involved in 28 percent of all incidents. Microsoft Windows and Internet Explorer were involved in about 3 percent of incidents, according to the survey.

The Department of Homeland Security recently said computer users should disable Java. At first this seems odd. The vulnerability in question is only in Java 7. So why not go back to Java 6? Well, Java 6 has vulnerabilities too, which is why DHS and others have recommended getting to 7. Also, starting in 7, the automatic upgrades are more aggressive. So going backwards is probably not a great idea. (If just happens I had to go backwards to get a tool I needed to work and forgot to go back forward.)

Also, for a similar situation back in August the recommendation was to make the browser prompt before allowing Java to run. The strategy is just stop Java entirely. Apple has removed Java browser plugins. That could work too. Except for bad, bad software like ours (sorry, sarcasm if you could not tell) which makes use of a few applets. In the last week I have gotten a request to add another applet.

A fix to Java 7’s vulnerabilties should be available in a couple days.

Collusion on Firefox

As we browse the Web, our browsers picks up cookies. Many sites will give our browser advertiser’s cookies. More importantly, the advertiser’s servers can look to see whether we have their cookies and where we obtained them. This is how they record our browsing habits. The more places they advertise, the better they are able to track us.

Collusion is an addon for Firefox detects the cookies added to my browser in order to identify the parties tracking me across sites are. For example, I just installed it and visited Google which dropped cookies for doubleclick, rubicon, bluekai, and others. I then went to the New York Times web site which added Nielson, Doubleplex, and other such as doubleclick.

This is going to occupy me for days… Maybe even weeks.

Browser Checker Inconsistent With Bb Wiki

The below text is from a ticket I opened with Blackboard this morning.

I used this unix command to dump a list of all supported browsers from the browserchecker.xml.

grep -A 1 ‘supported=”true”‘ serverconfs/browserchecker.xml | grep descript | awk -F\> ‘{print $2}’ | awk -F\< ‘{print $1}’

The list of supported browsers does not match the list of supported browsers at Supported Technologies Vista 8.0 SP4+Re-Release which means users of unsupported browsers are not getting alerted to the fact they are using an unsupported browser.

This specifically arose because I’ve been depending on the wiki to describe which browsers are supported in my work for [ticket number]. Several recent cases I’ve reviewed were IE7 which the wiki says is unsupported on Vista 8.0.4. The browser checker says it is supported.

Here is the full list of supported browsers according to the browserchecker.xml file. Those in bold are supported according to the supported technologies wiki entry in the above link. By my count that is 6 supported out of the 22 listed. (Actually it is 46 listed but I consolidated those in the same version.) My favorite on the list is Netscape Navigator 5 which was never actually released for the general public.

Netscape Navigator 5.x

Netscape Navigator 7.x

Microsoft Internet Explorer 5.1 (Mac OS)

Microsoft Internet Explorer 5.2 (Mac OS)

Microsoft Internet Explorer 5.5

Microsoft Internet Explorer 6.0

Microsoft Internet Explorer 7.0 (only on Windows Vista)

Microsoft Internet Explorer 8.0

AOL Version 5.x(MAC)

AOL Version 9.x

AOL for Mac OS X

Safari Version 1.2

Safari Version 1.3.x

Safari Version 2.x

Safari Version 3.x

Safari Version 4.x

Mozilla Version 1.7

Firefox Version 1.0

Firefox Version 2.0

Firefox Version 3.0

Firefox Version 3.5

Firefox Version 3.6

When To Upgrade

After Firefox just upgraded, I noticed it did a check to on the compatibility of the Add-Ons I have. Should any be incompatible, then the add-on gets disabled. The rationale being, “Add-Ons which do not work under the current version should not be enabled.”

Seems like I as the user of the software really ought to have a choice:

  1. (Current) Immediately upgrade the browser and disable any incompatible add-ons.
  2. Check add-on compatibility first and delay the browser upgrade until add-ons are all compatible.
  3. Check add-on compatibility first and prompt the user to choose when to upgrade. (Whether #1 or #2 is desirable.)
  4. Allow the user to choose which add-ons are too important to be disabled and delay the browser upgrade until an add-on version is available which is compatible. Then offer to upgrade both.

Maybe not enough people care Mozilla takes away their functionality?


(This is an post I wrote back in November but didn’t publish…. Until now. Have fun!)

Mitigated speech gets a lot of use by people trying not to offend. All too often, people who have been hurt because of mitigated speech question what isn’t being told as though the omission or gaps are intentionally deceptive.

What are or are not supported browsers came up again. The trick here is the mitigated speech used with the levels of support. I assume the intent is clarity.

  • Certified – supported with complete testing done.
  • Compatible – supported with some testing done.
  • Provisional – supported with some testing done before official release.

Certified is taken as supported by all parties. Compatible and Provisional are interpreted as not supported because the complete testing has yet to be done. I think Blackboard’s intent was to mark them as supported but qualify how customers might encounter issues due to not fully testing. This means Blackboard is interested in learning about the problems encountered in order to address them.

At least that is my interpolation. Mmmmmm the Kool-Aid is good.

Useful User Agents

Rather than depend on end users to accurately report the browser used, I look for the user-agent in the web server logs. (Yes, I know it can be spoofed. Power users would be trying different things to resolve their own issues not coming to us.)

Followers of this blog may recall I changed the Weblogic config.xml to record user agents to the webserver.log.

One trick I use is the double quotes in awk to identify just the user agent. This information is then sorting by name to count (uniq -c) how many of each is present. Finally, I sort again by number with the largest at the top to see which are the most common.

grep <term> webserver.log | awk -F\” ‘{print $2}’ | sort | uniq -c | sort -n -r

This is what I will use looking for a specific user. If I am looking at a wider range, such as the user age for hits on a page, then I probably will use the head command to look at the top 20.

A “feature” of this is getting the build (Firefox 3.011) rather than just the version (Firefox 3). For getting the version, I tend to use something more like this to count the found version out of the log.

grep <term> webserver.log | awk -F\” ‘{print $2}’ | grep -c ‘<version>’

I have yet to see many CE/Vista URIs with the names of web browsers. So these are the most common versions one would likely find (what to grep – name – notes):

  1. MSIE # – Microsoft Internet Explorer – I’ve seen 5 through 8 in the last few months.
  2. Firefox # – Mozilla Firefox – I’ve seen 2 through 3.5. There is enough difference between 3 and 3.5 (also 2 and 2.5) I would count them separately.
  3. Safari – Apple/WebKit – In searching for this one, I would add to the search a ‘grep -v Chrome’ or to eliminate Google Chrome user agents.
  4. Chrome # – Google Chrome – Only versions 1 and 2.

Naturally there many, many others. It surprised me to see iPhone and Android on the list.

Better CE/Vista Web Server Log

Some support tickets are more easily solved by knowing both user behavior and environment. An often helpful piece of information is what web browser they used. To add this, shut down the cluster, edit /VISTA_HOME/config/config.xml to include the cs(User-Agent), and start the cluster. This line will need to appear for every node. At startup, the nodes will download a new copy of the file.

<elf-fields>date time time-taken c-ip x-weblogic.servlet.logging.ELFWebCTSession sc-status cs-method cs-uri-stem cs-uri-query bytes cs(User-Agent) x-weblogic.servlet.logging.E LFWebCTExtras</elf-fields>

cp config.xml config.xml.bak
sed -s s/bytes x-/bytes cs(User-Agent) x-/g config.xml.bak > config.xml

Probably this could be edited in the Weblogic 9.2 console. I haven’t looked yet.

Blackboard Learn Password Changes

Normally when presenting the opportunity to change a password, a user is required to provide the current password in addition to the new. It ensures the one changing the password already knows the password. 

According to Olaf Ritman, Blackboard Academic Suite 6, 7, 8 and Learn 9 ignore asking for the current password. Can anyone with access to one of these confirm?

We run Blackboard Vista 3 and 8. Neither have this particular issue. Since our product is the end of the line and Learn is the future, I pay a little more attention to what is happening on the other side of the academic house.

Any thoughts on the scale of this as a security risk? Olaf makes the point any user leaving the browser logged into the site could have their password changed.

How Not To Break a Frame


<script language=”Javascript” type=”text/javascript”>
if (top != self)
top.location = window.location;


<script language=”Javascript” type=”text/javascript”>
if (top != self)
top.location = “/webct/urw/lc18361011.tp0/logonDisplay.dowebct”;

The problem with incorrect is the address used here is not the address in the location bar.  The one in the location bar has the values required to login. Instead I get something which causes users to be unable to login. Example: So we send someone to They get redirected to another address in which we provide the glicid, insId, and insName. Correct breaks the frame and gives the browser back the same address. Incorrect breaks the frame and gives the browser back a different, non-functional address. Bad. Bad. Bad.

WebCT Vista 3 used the Correct JavaScript which just passes back the address used. Blackbord Vista 8 for some reason changes what worked to Incorrect.

Yay for first day of classes.


It gets better… Bb Vista’s Custom Login and Institution List pages are unaffected (aka use the Vista 3 style JS). Only going to the generated logon page, loginDisplay.dowebct, has the issue.