Changes to release build process in 3.6.9 and up
Xeno86
Let's begin with introduction.
I am a developer of Windows NT compatibility layer project for Windows 98/Me, KernelEx.
So far we've been successfully running Mozilla Firefox 3.x on these unsupported systems, patching the system and implementing API calls required to maintain compatibility with Firefox browser. Everything was good until the release of 3.6.9.
In 3.6.9 and recently released 3.6.10 there are problems displaying background images/colors (screenshot links below).
There are even problems with simple html:
<html><head></head><body bgcolor="#000000"><font color="#ff0000">hello world</font></body></html>
However these problems didn't appear with 3.6.9pre/3.6.10pre and don't appear with latest 3.6.11pre nightly Namoroka builds.
We have compared sources of 3.6.8 and 3.6.9 builds, read hg changelogs and couldn't find relevant changes.
So we suspect that the build process has changed somehow in the meantime.
So these questions arise:
* Why the problem exists in release builds and not in nightlies?
* What are the differences (besides branding) between nightly Namoroka builds and official Firefox 3.6 builds?
* What has been changed in the build process between 3.6.8 and 3.6.9 that could cause mentioned problems?
I hope I posted this in proper the list, if not then let me know where I should post this.
-Xeno86, KernelEx developer
http://kernelex.sourceforge.net/
Image links:
Firefox 3.6.8 - http://i51.tinypic.com/20fc9b4.png
Firefox 3.6.9 - http://i55.tinypic.com/29w90td.png
Namoroka 3.6.11pre - http://i54.tinypic.com/2pop2dj.png
Nick Thomas
You've asked in the right place. I'm surprised you've found that
difference between recent release builds and 'old releases & recent
nightlies'. AFAICT we haven't changed the machines that compile Firefox
in any way that would cause this. The nightlies of the 16th and 17th
actually came from the same machine that did the 3.6.10 release.
The only differences between the nightly and release build configs are
the branding and the 'channel' for requesting updates.
Are you using the same profile for all those screenshots ? Does it still
happen with a new profile ?
Nick Thomas (a Firefox release engineer)
Xeno86
Thanks for fast reply. I've done further research with different setups.
I have tried both upgrading Firefox from 3.6.8 to 3.6.9/3.6.10 and clean installs, deleting profile data. On updated and vanilla systems.
First of all, the problem appears to be isolated to Windows 98 SE system, while other systems supported by KernelEx - Windows 98 FE and Windows Millennium appear to be unaffected.
Previously posted screenshots were taken from development system with lots of installed applications and various system updates.
I redid my test with fresh (vanilla) install of Windows 98 SE system, containing only basic drivers and stable KernelEx 4.0 Final 2 release, and installed Firefox 3.6.10 on top of that. In the result I was facing the exact same issues as before, while 3.6.8 and Namoroka nightlies were working okay.
The problem has been reproduced on all of our five different 98SE setups and also reported by our users:
http://sourceforge.net/projects/kernelex/forums/forum/924679/topic/3848072
http://kernelex.sourceforge.net/2010/09/rc-2-and-rc-3-pulled-down/#comments
It is important to us to keep Mozilla Firefox browser compatible with KernelEx.
-Xeno86, KernelEx developer
http://kernelex.sourceforge.net/
Ehsan Akhgari
Do you by any chance see this behavior when you paste this code into an
editable field?
Cheers,
Ehsan
Xeno86
The problem has been identified and fixed in KernelEx.
The root cause of the issue was the usage of uninitialized structure under Windows 9x by Firefox in the code that switches Firefox to special high contrast mode - hence the random behaviour which we attributed to differences in the build system.
The problem lies in http://mxr.mozilla.org/mozilla1.9.2/source/widget/src/windows/nsLookAndFeel.cpp#458
The code:
456 HIGHCONTRAST contrastThemeInfo;
457 contrastThemeInfo.cbSize = sizeof(contrastThemeInfo);
458 ::SystemParametersInfo(SPI_GETHIGHCONTRAST, 0, &contrastThemeInfo, 0);
459
460 aMetric = ((contrastThemeInfo.dwFlags & HCF_HIGHCONTRASTON) != 0);
In the case of Windows 9x call to SystemParametersInfo fails and leaves contrastThemeInfo structure uninitialized.
There are two reasons for that:
1) arguments to the call are wrong, uiParam argument should be equal to structure size, according to MSDN
2) there might be no Accessability Pack installed (which is optional on Windows 9x)
The correct code:
456 HIGHCONTRAST contrastThemeInfo;
457 contrastThemeInfo.cbSize = sizeof(contrastThemeInfo);
458 BOOL success = ::SystemParametersInfo(SPI_GETHIGHCONTRAST, sizeof(contrastThemeInfo), &contrastThemeInfo, 0);
459
460 aMetric = (success && (contrastThemeInfo.dwFlags & HCF_HIGHCONTRASTON) != 0);
Could anyone with commit access submit this fix?
We have implemented a fix in KernelEx 4.5 RC 4, through which SystemParametersInfo - SPI_GETHIGHCONTRAST call has same behaviour as on Windows NT.
Thanks for your time.
Jean-Marc Desperrier
> In the case of Windows 9x call to SystemParametersInfo fails and leaves contrastThemeInfo structure uninitialized.
> There are two reasons for that:
> 1) arguments to the call are wrong, uiParam argument should be equal to structure size, according to MSDN
> 2) there might be no Accessability Pack installed (which is optional on Windows 9x)
> Could anyone with commit access submit this fix?
I created bug 599311 with your explanation, proposed patch, and
reference to you as the original author of the report.
https://bugzilla.mozilla.org/show_bug.cgi?id=599311
I suggest you open an account on bugzilla and then ask for editbug
privileges, with references to that bug, and to your work in the
KernelEx project.