Jump to content

My Browser Builds (Part 3)


Recommended Posts

On 7/25/2021 at 2:22 PM, modnar said:

Thank you roytam1 for your work on these browsers.

I use Serpent/UXP on WinXP and was wondering if there is any solution to 23:18 problem on Youtube (video does continue but the pauses are quite annoying).

I also observed similar pause (where video didn't continue) on Rumble at 25:12 or so.

I use ublock_legacy (latest) in Serpent/UXP and these extensions.

I guess this is my cue to stop procrastinating and finally post the fix I made for this :) I've had a few people test it for 4 months now on all kinds of sites on both XP x86 and x64, and the jury says this indeed fixes the 2x:xx video stoppage issue and doesn't seem to introduce any new problems. I honestly didn't intend for the testing period to be quite this long, but summer heat can have a detrimental effect on one's brain and thus plans. :D

Since my own browser builds are based on Centaury, but I still consider myself a (lurking) MSFN patriot and this is the home of @roytam1's Serpent, I'm just going to post the fixed media/libcubeb/src/cubeb_winmm.c on Pastebin to avoid playing favorites (and signing up on Github ;)) I'm not sure how often @feodor2 visits here these days, so maybe someone on Github could mention this in https://github.com/Feodor2/Mypal/issues/1 if he doesn't pick this up soon enough.

What has been tested:

  • MP4/VP9/VP8 (and plain audio MP3/etc)
  • streaming/local
  • chunked/single-file
  • sped-up/slowed-down
  • 27+ hrs long playback (see the technical details for why)
  • Youtube/Twitter/Facebook/Instagram/TV station streams/etc/etc (nor did we forget p0rn/pirate sites, which of course are no different from a technical POV... :P).
  • Among other things, a 75-year old lady watched the entirety of Prince Philip's funeral with this fix in effect and had no complaints. :D

What has NOT been tested:

  • Pale Moon-based builds (as opposed to Basilisk), because I don't use NM or Mypal. Since this is a UXP platform level fix, the front-end should have no effect.
  • I obviously don't have access to every sound card out there, but since the MS driver causing these problems should be common in all configurations, I'd expect the fix to work with pretty much every card.
  • new-fangled formats like AV1 (I'd expect them work, though).
  • DRM-ed streams, since no Widevine on XP (but again, this should work with those as well if DRM itself worked).

 @roytam1, @feodor2 I didn't create a preference for turning this fix off, because it turned out the normal pref system is no longer compatible with C code, and once it became evident enough that the fix was pretty solid, I didn't feel like hacking something together to make preffing work for a library-level change like this. You're welcome to pref it, of course, but based on the length of testing with no issues discovered, I dare claim it's safe to include without a pref.

Here's a general overview of why this problem was happening (you may be surprised :ph34r:):

Spoiler

Basically, this was always an audio problem, even though it manifested as a video freeze. The idea is that an A/V stream (in this case, "stream" means linear playback starting from any position with possible pausing, but no seeking/jumping in either direction) should always move forward, but due to an MS audio driver bug the audio position counter overflows (effectively resets) and appears to move backward. The coupled video stream sees this, expects it to be a short-term stutter issue and basically goes "OK, I'll wait a bit until the audio starts moving forward again" - and ends up staying like this, because the audio can't get its reported position past the overflow point. Since, ironically, this doesn't actually affect audio playback, the user reasonably but wrongly assumes that it's a video issue...

I have to say I was always curious about this issue, but since it was a minor annoyance and easy enough to work around wirh a couple of key presses, I never felt compelled enough to spend time setting up the Mozilla build environment to really get into it while official Firefox was still XP compatible. But, since I've started doing my own builds now anyway, there was no longer any excuse not to investigate this. I was pleased to discover that my hunch about this being an overflow issue was correct, although I never considered the possibility of audio being the actual culprit. I've no idea how Mozilla managed to keep this bug around ever since Firefox 15.0 when it was first introduced by setting cubeb as the default audio library and deprecating libsydneyaudio (or, rather, it was made more manifest; it had also existed with libsydneyaudio in a much less obvious form, occurring roughly after every 3 hrs).

And, some more technical specifics, incl. about where the 2x:xx times come from (this is also included as a comment in the source code):

Spoiler

Microsoft wave audio docs say "samples are the preferred time format in which to represent the current position", but relying on this causes problems on Windows XP, the only OS cubeb_winmm is used on.

While the wdmaud.sys driver internally tracks a 64-bit position and ensures no backward movement, the WinMM API limits the position returned from waveOutGetPosition() to a 32-bit DWORD (this applies equally to XP x64). The higher 32 bits are chopped off, and to an API consumer the position can appear to move backward.

In theory, even a 32-bit TIME_SAMPLES position should provide plenty of playback time for typical use cases before this pseudo wrap-around, e.g:

(2^32 - 1)/48000 = ~24:51:18 for 48.0 kHz stereo;
(2^32 - 1)/44100 = ~27:03:12 for 44.1 kHz stereo.

In reality, wdmaud.sys doesn't provide a TIME_SAMPLES position at all, only a 32-bit TIME_BYTES position, from which wdmaud.drv derives TIME_SAMPLES:

SamplePos = (BytePos * 8) / BitsPerFrame,
where BitsPerFrame = Channels * BitsPerSample,

Per dom\media\AudioSampleFormat.h, desktop builds always use 32-bit FLOAT32 samples, so the maximum for TIME_SAMPLES should be:

(2^29 - 1)/48000 = ~03:06:25;
(2^29 - 1)/44100 = ~03:22:54.

This might still be OK for typical browser usage, but there's also a bug in the formula above: BytePos * 8 (BytePos << 3) is done on a 32-bit BytePos, without first casting it to 64 bits, so the highest 3 bits, if set, would get shifted out, and the maximum possible TIME_SAMPLES drops unacceptably low

(2^26 - 1)/48000 = ~00:23:18;
(2^26 - 1)/44100 = ~00:25:22.

To work around these limitations, we just get the position in TIME_BYTES, recover the 64-bit value, and do our own conversion to samples.

EDIT: Writing this up amply reminded me how much I LOVE :no: making long posts using this board's post editor... BBCode FTW!:thumbup

Edited by mixit
Link to comment
Share on other sites


9 hours ago, mixit said:

I've no idea how Mozilla managed to keep this bug around ever since Firefox 15.0

Don't forget that Google knew about such problems and abused that knowledge, though Google coders working with Mozilla team should rather help to make fixes. They even might deliberately keep bugs unfixed.

Mozilla claims Google has made YouTube perform worse on Edge and Firefox

Mozilla engineer says Google slowed YouTube down on non-Chrome browsers

Former Mozilla exec: Google has sabotaged Firefox for years

 

Link to comment
Share on other sites

Nothing really new - they have all done it over the years.

Android was once caught rigging their phones to falsely score high on very popular "benchmarks" but would perform poorly in "real-world" scenarios.

And Android got caught doing that just a few short years after they themselves caught Samsung cheating benchmarks on Note 3 and Galaxy S4.

AMD's entire Athlon line of CPUs were all premised on "We know the clock is only 1.8 GHz, but it performs equally to a 2.8 GHz" (which they did, btw, I was an AMD over-clocker for years) - though I guess that's more "marketing" then "cheating".

Bing used to always load faster on IE then it did in Firefox.

Google probaby used to do the same thing, but no reason to anymore, isn't Google the default search engine for Firefox?

It's probably more of a smartphone thing nowadays, cheat your "score" for the sake of sales.

Though I have always felt that if the "turbo engine" was marketed as "fuel-efficient" instead of "performance", then all cars would have turbos in the vein of "going green".

"Why did you buy such a fast car?"  "I didn't buy it because it's fast, I bought it because it's the most fuel-efficient in its class."

Link to comment
Share on other sites

On 7/26/2021 at 5:00 PM, RainyShadow said:

@mixit, @roytam1

Just out of curiosity, roughly how much disk space is needed to compile a browser currently (Serpent52/NM27/NM28/Centaury) - source + dependencies + intermediate files created when building ?

Don't count the compilers/IDE/etc.

Let's see here... Looks like my latest Centaury build uses roughly 6.2 GB altogether, 1.4 GB for the source and 4.8 GB for the "object directory" with build results. This is a release build, debug would be somewhat larger - so let's say 7-8 GB in total.

MozillaBuild is roughly 0.8 GB. The full DirectX SDK is 1.2 GB installed (although you really only need a few MB from it). For Windows 10 EWDK based builds (like @feodor2 does them) the EWDK .iso (that you can mount as-is) is 6-9 GB depending on version (getting bigger), but you don't have to install VS and the Windows SDK, so you can still save quite a bit that way.

It was pretty funny to see Moonchild arrogantly lecture feodor2 that he didn't "understand how software in general works" because feodor2 didn't want to install all the extra bloat that comes with VS, whereas Mozilla have been using stripped down tools packages since well before Firefox 52.0 that UXP is based on :P (see the history of their toolchain packaging script). (OK, so they do the install once, but then package the components they actually need and use that package for subsequent builds.) If you did that (installed, repackaged, uninstalled) with the current official MCP requirements for Pale Moon/Basilisk, you'd end up with only 1.3 GB for all the required VS and SDK stuff, huge space savings!
 

On 7/26/2021 at 6:49 PM, we3fan said:

Thanks for this mixit.

How to implement this fix?

You're very welcome :) Since I don't plan on distributing my own builds publicly, I guess you'll have to wait until @roytam1 and/or @feodor2 merge this into their builds, so quite possibly only until this week-end for Serpent (although they'll likely want to spend a bit more time testing this on their own).

 

On 7/27/2021 at 8:37 AM, we3fan said:

Hi guys, if I want to apply mixit's fix on Firefox ESR 52.9.0 for example, where do I need to put this file cubeb_winmm.c? A little help?

You'd need to rebuild the whole application, replacing media/libcubeb/src/cubeb_winmm.c in the source code. Unfortunately this is not something that can be applied "on-the-fly".

Edited by mixit
Link to comment
Share on other sites

47 minutes ago, roytam1 said:

LGTM :thumbup

will commit it in short period.

EDIT: committed in goanna3 and 4 repo, other repos will be followed later.

Cool, thanks! :D And you even gave (ample!) proper credit and everything, quite unlike the "thieving hacker" image certain folks at MCP like to project of you, lol! :whistle:

Edited by mixit
Link to comment
Share on other sites

kind-of off-topic:

lately I'm a bit busy on FLOSS project(s). For example, I co-op with mksh's author to port mksh to SCO UNIX 3.2:
https://github.com/MirBSD/mksh/compare/ec07d019c758de5a457e6e2e896cc6314fa58d24...345f09eb1d9bc3879ebce9728ed71a762a36c4ea
and hoping to port(kind-of) to Xenix.

or raising suggestions on https://github.com/jhhoward/MicroWeb/issues

Link to comment
Share on other sites

On 7/25/2021 at 8:48 PM, Usher said:

For 720p and higher Youtube uses MPEG DASH standard - it downloads separately audio and video streams divided in segments.

Actually YouTube offers several format options for 720p. Format 22 is a single file.

E.g. for this video (found formats with yt-dlp, using the following command):

yt-dlp -F https://www.youtube.com/watch?v=I79CQUTO5II


 

22  mp4  1280x720   30  |             852k https | avc1.64001F    852k mp4a.40.2   0k 44100Hz 720p
136 mp4  1280x720   30  |  89.77MiB   723k https | avc1.4d401f    723k                        720p (throttled), mp4_dash
247 webm 1280x720   30  |  88.94MiB   716k https | vp9            716k                        720p (throttled), webm_dash
398 mp4  1280x720   60  |  108.10MiB  871k https | av01.0.08M.08  871k                        720p60, mp4_dash


480p however has only Dash:

397 mp4  854x480    30  |  42.61MiB   343k https | av01.0.04M.08  343k                        480p, mp4_dash
135 mp4  854x480    30  |  29.41MiB   236k https | avc1.4d401f    236k                        480p, mp4_dash
244 webm 854x480    30  |  32.46MiB   261k https | vp9            261k                        480p, webm_dash

But note "throttled" in the above output. Maybe that can be the culprit?

cc @we3fan

Edited by nicolaasjan
Link to comment
Share on other sites

Thanks for the detailed answer, @mixit

I already have VS 2019 and DirectX SDK installed, part of the reason i'm left with less than 40GB space on the C: drive, lol.

Hopefully using another drive won't mess things if/when i try building something bigger (like a browser) sometime in the far future.

Still no clue what i'm doing in that damn IDE, especially when a project won't build as is, but needs some fixing first.

A simple "make config / make install" or the Arduino IDE come a lot more easier.

 

P.S. there is HttpDisk, which allows mounting iso and disk images over the internet, no need to download several GBs to extract only a few files.

Edited by RainyShadow
Link to comment
Share on other sites

On 7/27/2021 at 1:43 AM, Usher said:

Don't forget that Google knew about such problems and abused that knowledge, though Google coders working with Mozilla team should rather help to make fixes. They even might deliberately keep bugs unfixed.

Mozilla claims Google has made YouTube perform worse on Edge and Firefox

Mozilla engineer says Google slowed YouTube down on non-Chrome browsers

Former Mozilla exec: Google has sabotaged Firefox for years

 

(Sorry, didn't have time to respond to this before.)

I agree with your general point, but I'm not sure how much Google is to blame in this particular case. The thing is, programmers often tend to be pretty lazy when having to do maintenance tasks, because these aren't seen as "cool" and "innovative"... And this bug is a bit of a special case, because it takes almost 30 min to run a single test case, whether you're trying to track down where the regression originated, or trying to fix it.

Let me give you a rough rundown of the process I went through with this (let's skip this long story for them normal people ;); and this isn't about me looking for extra credit, honest! :D)

Spoiler
  • This issue is usually seen on Youtube, does it also happen with other streaming platforms? Yes.
  • Does it matter if the stream is chunked or using a single media file? No.
  • Does it also happen with local .mp4 playback? Yes.
  • Does it happen only with MPEG-4/H.264 or also with VP9? Also with VP9, but the timing is different. (It later turned out that was because MPEG-4 streams typically use 44.1 kHz audio, whereas VP9/8 use 48.0 kHz. But at this point I had no clue this was an audio issue.)
  • Was there ever a time when this didn't happen with MPEG-4/H.264? With VP9? Trying out the FF versions where these formats were first introduced, apparently the issue was always present.
  • Uh, so what about VP8, does it happen with that? Yes.
  • Was there ever a time when this didn't happen with VP8? After going back even more FF versions, apparently the bug wasn't there in FF 14.0.
  • So, lets narrow it down to the nightly where this happened. Sifting through, eventually found the failing nightly.
  • Let's see what commits were made for this nightly. This, that, etc. look irrelevant, but there is an audio-related change, flipping a preference to default to the cubeb library instead of the former default sydneyaudio. Say WHAT, this isn't actually a video issue?
  • So, let's try flipping the media.use_cubeb pref back and forth, is that it? Yes, cubeb has the issue, sydneyaudio doesn't.
  • Let's try it with the 14.0 and 15.0 release versions. Same thing, cubeb is the problem.
  • Let's turn on a bunch of A/V related logging and see what it shows. Unable to pinpoint the issue with existing logging.
  • Looks like no getting further with existing binaries, time to set up VS 2010 & the works and start working with the code. EDIT: Ah, the good old days when VS still worked on XP! :lol:
  • Visual inspection of the code doesn't reveal anything blatantly obvious.
  • Add a bunch of extra logging to both cubeb and sydneyaudio functions, run comparative tests. Hmm, cubeb stream position resets and sydneyaudio's doesn't, but why?
  • One is using TIME_SAMPLES, the other TIME_BYTES, could that be it? Kludge some code, that indeed seems to be it, TIME_SAMPLES has a problem.
  • OK, so could just change cubeb to use TIME_BYTES instead, but I want to know WHY this is happening, because otherwise I can't be confident that this is REALLY enough to fix this.
  • Time to whip out some serious debugging and disassembly skills :worship:!
  • Ah, OK, so wdmaud.drv seems to be doing this incorrect shifting thing and getting rid of the upper bits, so that seems to be it, but I still don't know if there aren't more factors at play here and slogging through disassembly is slow going...
  • Oh, but wait, wasn't there an XP source code leak recently, maybe I can verify my findings with that? Eventually managed to track down the source code and verify that indeed there is a shifting bug in wdmaud.drv, but even TIME_BYTES would still have an issue with very long streams because of the API limit of 32 bits.
  • But, since the source for wdmaud.sys shows that it guarantees no backward movement for its part, I can implement the perfectionist fix :cool: of restoring the 64-bit position value in cubeb.
  • Woohoo! :cheerleader:But I still have to test, test, test, test... Including with 27+ hrs of playback... :blink:
  • Here ends the abbreviated version of my great journey, :D

OK, so now consider that during virtually every step of this, you have to run a whole lot of 30 min (or longer) tests to make sure of your guesses or fixes. I am, of course, a great guy and all :thumbup, but even with my highly vested hobbyist interest in solving this issue it took me several months to get through this all. Obviously not months of straight work on this alone, and obviously I didn't just sit around gaping at the screen every time I ran a test, but started the test and then did something else while it ran, but the whole thing still took time.

Now, imagine I was an elite coder working at Mozilla :D, and generally supposed to work on some other stuff besides this. And, let's say you were my manager. :D Are you sure you'd let me spend all this time on this one, apparently (but really not) intermittent issue that seems to be affecting only a few people (really affecting all, but 99.99% of those people wouldn't put 2 and 2 together and notice the very specific interval and would instead write these freezes off as internet issues or whatever else) on a "legacy" OS that doesn't have that long to live anyway (or so you think, not knowing about POSReady, and MSFN :P )? And would I, an elite Mozilla engineer :blushing:, want you to make me spend my precious time on something like this? I mean, even without the whole Windows driver dive and leak hunting thing they obviously wouldn't get into (the leak hadn't happened yet, either), it's a lot of work that isn't "cool", nor "innovative"! :zzz:

This is not to say that I excuse the fact that they don't even run tests for longer playback, etc., etc. We all know Mozilla has lots of problems with their attitude and policies, and there are many things they aren't doing that they should be doing (and vice versa). I definitely do blame them for letting this fall through the cracks and not doing more to fix this. But as far as Google goes, since they probably weren't using cubeb, maybe they themselves never ran into this bug (at least its more obvious, 2x:xx version), and since this isn't an issue specific to Youtube, I think I wouldn't blame them too much for this one.  But there is Microsoft, who introduced this bug in the first place with that pretty dumb coding error... :whistle:

Edited by mixit
Link to comment
Share on other sites

On 7/25/2021 at 10:14 AM, we3fan said:

Hi @modnar, I am not sure if we talk about the same issue.

When I watch youtube video with Firefox or Firefox-derived browser on 720p, often the audio will continue but the image will freeze for 7 seconds. This doesn't happen on 480p.

I have 2GB RAM, maybe upgrade to 4GB RAM would fix this, not sure.

Just to answer - I experience a ~16s freeze but I don't want to lower quality because of that, so 4GB of RAM doesn't help really. As @mixit said it's an audio bug in the library...

I have 4GB of RAM and a GTX 980 video card with SBAudigy2 and this should be enough for all my audio and video needs up to 1080p60fps (though I use 1680x1050 screen) and it works and now this fix - wow - something to look for in the next Serpent build. Mighty fine. :thumbup

 

On 7/26/2021 at 10:33 AM, mixit said:

I guess this is my cue to stop procrastinating and finally post the fix I made for this :) I've had a few people test it for 4 months now on all kinds of sites on both XP x86 and x64, and the jury says this indeed fixes the 2x:xx video stoppage issue and doesn't seem to introduce any new problems. I honestly didn't intend for the testing period to be quite this long, but summer heat can have a detrimental effect on one's brain and thus plans. :D

Since my own browser builds are based on Centaury, but I still consider myself a (lurking) MSFN patriot and this is the home of @roytam1's Serpent, I'm just going to post the fixed media/libcubeb/src/cubeb_winmm.c on Pastebin to avoid playing favorites (and signing up on Github ;)) I'm not sure how often @feodor2 visits here these days, so maybe someone on Github could mention this in https://github.com/Feodor2/Mypal/issues/1 if he doesn't pick this up soon enough.

What has been tested:

  • MP4/VP9/VP8 (and plain audio MP3/etc)
  • streaming/local
  • chunked/single-file
  • sped-up/slowed-down
  • 27+ hrs long playback (see the technical details for why)
  • Youtube/Twitter/Facebook/Instagram/TV station streams/etc/etc (nor did we forget p0rn/pirate sites, which of course are no different from a technical POV... :P).
  • Among other things, a 75-year old lady watched the entirety of Prince Philip's funeral with this fix in effect and had no complaints. :D

What has NOT been tested:

  • Pale Moon-based builds (as opposed to Basilisk), because I don't use NM or Mypal. Since this is a UXP platform level fix, the front-end should have no effect.
  • I obviously don't have access to every sound card out there, but since the MS driver causing these problems should be common in all configurations, I'd expect the fix to work with pretty much every card.
  • new-fangled formats like AV1 (I'd expect them work, though).
  • DRM-ed streams, since no Widevine on XP (but again, this should work with those as well if DRM itself worked).

 @roytam1, @feodor2 I didn't create a preference for turning this fix off, because it turned out the normal pref system is no longer compatible with C code, and once it became evident enough that the fix was pretty solid, I didn't feel like hacking something together to make preffing work for a library-level change like this. You're welcome to pref it, of course, but based on the length of testing with no issues discovered, I dare claim it's safe to include without a pref.

Here's a general overview of why this problem was happening (you may be surprised :ph34r:):

  Reveal hidden contents

Basically, this was always an audio problem, even though it manifested as a video freeze. The idea is that an A/V stream (in this case, "stream" means linear playback starting from any position with possible pausing, but no seeking/jumping in either direction) should always move forward, but due to an MS audio driver bug the audio position counter overflows (effectively resets) and appears to move backward. The coupled video stream sees this, expects it to be a short-term stutter issue and basically goes "OK, I'll wait a bit until the audio starts moving forward again" - and ends up staying like this, because the audio can't get its reported position past the overflow point. Since, ironically, this doesn't actually affect audio playback, the user reasonably but wrongly assumes that it's a video issue...

I have to say I was always curious about this issue, but since it was a minor annoyance and easy enough to work around wirh a couple of key presses, I never felt compelled enough to spend time setting up the Mozilla build environment to really get into it while official Firefox was still XP compatible. But, since I've started doing my own builds now anyway, there was no longer any excuse not to investigate this. I was pleased to discover that my hunch about this being an overflow issue was correct, although I never considered the possibility of audio being the actual culprit. I've no idea how Mozilla managed to keep this bug around ever since Firefox 15.0 when it was first introduced by setting cubeb as the default audio library and deprecating libsydneyaudio (or, rather, it was made more manifest; it had also existed with libsydneyaudio in a much less obvious form, occurring roughly after every 3 hrs).

And, some more technical specifics, incl. about where the 2x:xx times come from (this is also included as a comment in the source code):

  Reveal hidden contents

Microsoft wave audio docs say "samples are the preferred time format in which to represent the current position", but relying on this causes problems on Windows XP, the only OS cubeb_winmm is used on.

While the wdmaud.sys driver internally tracks a 64-bit position and ensures no backward movement, the WinMM API limits the position returned from waveOutGetPosition() to a 32-bit DWORD (this applies equally to XP x64). The higher 32 bits are chopped off, and to an API consumer the position can appear to move backward.

In theory, even a 32-bit TIME_SAMPLES position should provide plenty of playback time for typical use cases before this pseudo wrap-around, e.g:

(2^32 - 1)/48000 = ~24:51:18 for 48.0 kHz stereo;
(2^32 - 1)/44100 = ~27:03:12 for 44.1 kHz stereo.

In reality, wdmaud.sys doesn't provide a TIME_SAMPLES position at all, only a 32-bit TIME_BYTES position, from which wdmaud.drv derives TIME_SAMPLES:

SamplePos = (BytePos * 8) / BitsPerFrame,
where BitsPerFrame = Channels * BitsPerSample,

Per dom\media\AudioSampleFormat.h, desktop builds always use 32-bit FLOAT32 samples, so the maximum for TIME_SAMPLES should be:

(2^29 - 1)/48000 = ~03:06:25;
(2^29 - 1)/44100 = ~03:22:54.

This might still be OK for typical browser usage, but there's also a bug in the formula above: BytePos * 8 (BytePos << 3) is done on a 32-bit BytePos, without first casting it to 64 bits, so the highest 3 bits, if set, would get shifted out, and the maximum possible TIME_SAMPLES drops unacceptably low

(2^26 - 1)/48000 = ~00:23:18;
(2^26 - 1)/44100 = ~00:25:22.

To work around these limitations, we just get the position in TIME_BYTES, recover the 64-bit value, and do our own conversion to samples.

EDIT: Writing this up amply reminded me how much I LOVE :no: making long posts using this board's post editor... BBCode FTW!:thumbup

Hallelujah!!!

Now this is resolved! I'm very thankful for your time in fixing and testing and providing a fix, @mixit, for our favorite browser and of course @roytam1 for implementing it in all XP browsers!

WOOHOO! SuperSweet! Shaderlicious and such. :D:cool::thumbup

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...