I took a screenshot after installing on a windows 7 VM on the right. The left is view of the last page without Greasemonkey.

However the header is only removed on that first page. After searching the header came back.

I attached the errors from the Browser Console, if this is a Firefox issue we can file a bug in bugzilla, but this is not my technical expertise.

It also looks like the issue on github continued in this issue: https://github.com/greasemonkey/greas.../1970

With the infos from https://github.com/greasemonkey/greasemonkey/issues/1970 , I could write this workaround script for FF 31: https://www.eclipse.org/jdt/ui/scripts/jdtbugzilla-start.user.js

This template could help others create a workaround for their broken pages:

// ==UserScript==
// @name        Remove history.replaceState from buglist.cgi
// @description Removes history.replaceState from buglist.cgi to work around https://github.com/greasemonkey/greasemonkey/issues/1970
// @include     https://your/page*

// @version 1
// @grant       none
// @run-at document-start
// ==/UserScript==
history.replaceState = function(data, title, url) {
	console.log("caught history.replaceState(" + data + ", " + title + ", " + url + ")");
};

I cross referenced the post to the issue in github. Would this template replace the history record?

> Would this template replace the history record?

No, it effectively disables the history.replaceState() function. The URL in the history will not be updated any more, but that's less of an issue for me than not having the script run at all.

Note that my script just works for pages like Bugzilla that use the replaceState() function. For other pages, you may have to replace the pushState() function.

In https://github.com/greasemonkey/greasemonkey/issues/1970#issuecomment-50781923 , the Greasemonkey developer identified where GM fails, so I eventually expect a real solution from him (or a bug report for Firefox if he can't cope with FF's changed behavior).