IE7

Recap: In certain situations, jQuery’s $.browser.version will report IE 7 as version 6.

Considering the problem is due to IE 7 having an incorrect user-agent, I'm not sure that this problem was up to jQuery to solve. It would have required the user-agent parsing code to check non-user-agent properties...which is probably a bad idea.

I found out that my original code suggestions might fail in situations where IE 6 is using a 3rd party library to add XMLHttpRequest support, so here are my updated IE 6 and IE 7 detection suggestions:

Override the $.browser.version value:

jQuery.browser.version = jQuery.browser.msie &&
    parseInt(jQuery.browser.version) >= 6 &&
    typeof window['XMLHttpRequest'] == "object" ?
        "7.0" :
        jQuery.browser.version;

Add a new msie6 property:

jQuery.browser.msie6 = jQuery.browser.msie &&
    parseInt(jQuery.browser.version) == 6 &&
    typeof window['XMLHttpRequest'] != "object";

Keep in mind that $.browser is now deprecated, which means it will go away at some point in a future release. I'm not going to get into the object detection vs browser sniffing debate, but just be aware!

Opera 9.5

Recap: Opera, in an effort to follow standards, changed where it was storing the value for the viewport height.

This issue was fixed in jQuery Ticket 3117 by Ariel Flesler. If you have Opera 9.5, you can test the results on this page.

Safari 3 (Windows)

Recap: The following element would not be hidden in Safari: $("<div/>").hide().appendTo('body');

I found out that this issue also occurs in Safari 4! The original jQuery ticket I mentioned was marked as a duplicate, but the issue was fixed in ticket 1239.

Summary

Besides the problems with the IE user-agent, the jQuery developers implemented fixes for the two other browser issues that I had previously blogged about. jQuery 1.3.x has a number of new features and code improvements and continues to be, IMO, the best available JavaScript library.

While working on a new site design, I found an interesting bug in WordPress 2.7. I created two new pages to use as "Front page displays", one called Blog and one called Home. To create the pages, I clicked on Pages > Add New, entered a Title and clicked Publish.

I then went to my Reading Settings (Settings > Reading) and set the static Front and Posts page to the pages I just created. Going back to my site, I tested out the new static pages only to find they didn't work.

After a lot of time and troubleshooting, I noticed on the Pages screen that there were two copies of each page I had created - with one still labeled as a Draft. After even more time troubleshooting, I finally discovered the issue. Unlike the Posts page, the Publish and Save Draft buttons are not disabled during an autosave. So, when I entered the Page title and clicked Publish, the autosave and publish requests were happening at the same time.

I opened a WordPress ticket and submitted a patch. The patch was applied by azaozz, but it looks like it won't be available until WordPress 2.8. To fix this bug yourself, open /wp-includes/js/autosave.js and change all occurrences of #submitpost to .submitbox:

function autosave_enable_buttons() {
	jQuery(".submitbox :button:disabled, .submitbox :submit:disabled").attr('disabled', '');
}

function autosave_disable_buttons() {
	jQuery(".submitbox :button:enabled, .submitbox :submit:enabled").attr('disabled', 'disabled');
	setTimeout(autosave_enable_buttons, 5000); // Re-enable 5 sec later.  Just gives autosave a head start to avoid collisions.
}

Now the buttons will be disabled during an autosave, just like it does on the Posts page.

During the time that I've been using jQuery (about a year now), I've run into three fairly significant browser issues. Between IE, Firefox, Safari, and Opera, Firefox is the only browser that I have yet to experience any issues with (related to jQuery, of course).

IE 7

In certain situations, jQuery's $.browser.version will report IE 7 as version 6. Jamie Thompson noted one possible situation on his blog, but typically the issue is caused due to the fact that some copies of IE 7 included MSIE 6.0 within its user-agent string.

There is a jQuery Ticket open for the issue, but a solution has not been chosen. Based on some ideas that Jamie had, I came up with a possible solution by overriding the $.browser.version value:

jQuery.browser.version = jQuery.browser.msie &&
    parseInt(jQuery.browser.version) >= 6 &&
    window["XMLHttpRequest"] ?
        "7.0" :
        jQuery.browser.version;

Additionally, there are situations when I'm just looking for IE 6:

jQuery.browser.msie6 = jQuery.browser.msie &&
    parseInt(jQuery.browser.version) == 6 &&
    !window["XMLHttpRequest"];

It appears that these issues were resolved in IE 8 (at least in the beta version), but until jQuery releases a "fix", you'll have to deal with unreliable browser version detection in IE 7, or use one of the suggestions above.

Opera 9.5

I discovered an issue getting the viewport height in Opera 9.5 while testing my rewrite of SimpleModal. It turns out that Opera, in an effort to follow standards, changed where it was storing the value for the viewport height...breaking the way jQuery was getting the value. Previously, the value was stored in document.body["clientHeight"], but in 9.5 it was moved to document.documentElement["clientHeight"]. There is also a jQuery Ticket open for this issue, and a patch has been added by Ariel Flesler.

For SimpleModal, I've added code that will fix the issue until it is fixed in jQuery:

// fix a jQuery/Opera bug with determining the window height
var h = $.browser.opera && $.browser.version > "9.5" &&
    $.fn.jquery <= "1.2.6" ?
        document.documentElement["clientHeight"] :
        $(window).height();

Safari 3 (Windows)

This is the smallest of the three issues, but annoying none-the-less. Take the following example:

$("<div/>").css({
    background: "#336699",
    color: "#fff",
    padding: "8px",
    width: "200px"
}).html("Loading...").hide().appendTo("body");

In Safari, the "loading" element will be visible when the page loads. In all other browsers, it is hidden (display:none). The issue occurs because the jQuery hide() function is supposed to look for "visible" elements and set the CSS display property to 'none'. However, in Safari, it appears that an element not yet in the DOM, already has a display property of 'none'...which sounds fine, right? It's not! Since it fails the visibility test, jQuery does not explicitly set the display property to "none".

Then, once the element is added to the DOM, it appears that Safari sets the elements display property to 'block'. So even though the intention was to have it "hidden", due to a Safari quirk (and lack of a jQuery internal solution), the element will be visible.

As I'm sure you've guessed by now, there is a jQuery Ticket open, but the suggestion is to just change the way you use jQuery. One suggestion is to move the .hide() after the .appendTo("body"). My problem with this is that it introduces the possibility of a flicker on the screen as the element is added and then hidden. The workaround I am using is to manually set the display property on the element:

$("<div/>").css({
    background: "#336699",
    color: "#fff",
    display: "none",
    padding: "8px",
    width: "200px"
}).html("Loading...").appendTo("body");

That concludes my notes about three browser issues I've encountered while using jQuery. If you've run into any issues where you've had to use a workaround, or have any other suggestions for the workarounds I used, feel free to mention them below!

And the moral of the story...use Firefox! :)

After making some changes to my app, I went to test it out, only to get an Vista notification stating that httpd.exe had shut down unexpectedly. I checked my Event Viewer Application logs and found an Error with the following details:

Faulting application httpd.exe, version 2.2.6.0, time stamp 0x46deb625,
faulting module ntdll.dll, version 6.0.6001.18000, time stamp 0x4791a7a6,
exception code 0xc00000fd, fault offset 0x00065950, process id 0x998,
application start time 0x01c8db31c2d05070.

After a bit of debugging and scratching my head, I remembered that I had deleted a "view helper" file that I had created, but forgot to remove the reference to it (var $helpers = array()) from my app_controller.php file...doh!

I am a bit surprised that CakePHP wasn't able to catch this problem since it seems to catch so many other "missing" situations. Perhaps there is a way that CakePHP can prevent the issue...

ERROR - ParametersInterceptor.setParameters(204) | ParametersInterceptor - [setParameters]: Unexpected Exception caught setting '_' on 'class com.company.web.MyAction: Error setting expression '_' with value '[Ljava.lang.String;@1491ddc'

If so, it's because Struts 2 is parsing the query string/post data and trying to "set" a value for each parameter it finds.

I'm working on an Struts 2 application utilizing the jQuery JavaScript library for the UI and the Displaytag tag library for displaying tables.

With jQuery, I'm using the "no-cache" option (cache: false) on all Ajax calls, which adds "_=timestamp" to each request. Since I don't have a property called "_" in my Action class, I get an error (mentioned above) in my logs for each request.

Same with Displaytag, except the parameters causing errors are in the form of "d-#-X", where "#" is a unique id (usually 4 or 5 digits) and "X" is either p, s or o. They are used to determine the page (p) and/or the table sort order (o for asc/desc and s for which column).

The solution: configure Struts (struts.xml) to ignore these parameters:

<interceptors>
   <interceptor-stack name="defaultStack">
      <interceptor-ref name="params">
         <!--
            Excludes the jQuery no-cache _ parameter and
            the Displaytag d-#-X parameter(s)
         -->
         <param name="excludeParams">
            _,d-\d+?-[sop]
         </param>
      </interceptor-ref>
   </interceptor-stack>
</interceptors>

If you have a different parameters that are causing problems, just put them in the excludeParams node, comma separating multiple parameters.

However, the code that adds this 'no-cache' parameter does not check to see if it already exists and so under certain circumstances you can end up with URL's that look like:

http://mysite.com/file.html?_=1196716041523&_=1196716462963&_=1196716464245

It certainly makes the URL unique :)

I opened a ticket and submitted a patch, which was quickly optimized by a jQuery developer, davidserduke.

It's nice to see a project with responsive, helpful developers.

While working on a project using Struts 2, I was attempting to create a HTML button that looked something like:

<button type="button" class="button positive save">
    <img src="/images/tick.png" alt="Save"> Save
</button>

I followed the Struts 2 Tag Reference for the submit tag and tried the following:

<s:submit type="button" cssClass="button positive save">
    <img src="/images/tick.png" alt="Save"> Save
</s:submit>

Instead of rendering like my example above, it looks like:

<img src="/images/tick.png" alt="Save"> Save
<button type="submit" id="test_0" value="Submit" class="button positive save">Submit</button>

Not exactly what I had in mind... ;)

At first I thought that I was just doing something wrong, so I posed a question on the mailing list. Then after searching the list some more, I found that this was, in fact, a bug and that it had been previously reported and supposedly fixed.

I checked out the Struts 2 core project and started looking around in the code. I posted some of my thoughts and ended up creating a patch that added a new s:button tag.

Struts tries to render the button tag using the same code that is used to render the input tag. The two tags share a lot in common, however, there are some important differences between them. Mainly, the input tag does not have a body and uses its value attribute for its label, whereas the button tag must have a body, which is what is used as its label. Unless you required name/value information to be sent for the button, there is no need to include either of those attributes on the button tag.

It will be interesting to see if my patch is used...either way, it was fun to dig into the Struts code and it was a good learning experience.

Cannot load /usr/local/apache/libexec/mod_bwlimited.so into server: /usr/local/apache/libexec/mod_bwlimited.so: cannot open shared object file: No such file or directory

After a Google search, I found that I needed to run:

cd /usr/local/cpanel/apache

/usr/local/apache/bin/apxs -iac mod_auth_passthrough.c
/usr/local/apache/bin/apxs -iac mod_bwlimited.c
/usr/local/apache/bin/apxs -iac mod_log_bytes.c

I was able to start Apache afterwards and everything is back to normal...

Well, when I brought up the site, I got an error:

Fatal error: Unable to locate the requested file, log.php in <system_path>/system/core/Kohana.php on line 408

After a lot of digging, I found that there was a glob() call that was not behaving correctly. I narrowed it down to what I believe to be a bug in PHP with the glob() function, using the GLOB_BRACE flag, and using a pattern that includes a colon (as in {c:/firstFolderToCheck,c:/secondFolderToCheck}).

Assuming it turns out to be valid, I'm surprised that it hasn't been found/reported before...