views:

72

answers:

1

a page with a bit of MVC code:

<%=Html.SubmitButton("ChooseWebinar.Submit", "Continue to Registration Details")%><br/>

that generates an input button where the '.' is embedded in the name:

<input id="ChooseWebinar_Submit" name="Webinar.Submit" type="submit" value="Continue" />

At page load this control (the submit button) is hidden - when one of two different dropdowns registers a value, the button is shown:

function toggleChooseWebinarSubmit() {
if ($("#ChooseWebinar_RecordedWebinarId").val() || $("#ChooseWebinar_UpcomingWebinarId").val()) {
    $("#ChooseWebinar_Submit").show();
} else {
    $("#ChooseWebinar_Submit").hide();
}

I've just received a report from an IE8 user who says that after selecting a value in a dropdown, the button is _not displaying. I can't reproduce the condition (i've tried compatibility mode too).

Obviously the show/hide is targeting the 'ID' selector but i can't help but wonder about that period in the control's name.

Any known issues? - or perhaps the .change is problematic and the toggle's never getting called:

$(window).load(function() {
    toggleChooseWebinarSubmit();
    $("#ChooseWebinar_UpcomingWebinarId").change(function() {
        if ($(this).val()) {
            $("#ChooseWebinar_RecordedWebinarId").val("");
        }
        toggleChooseWebinarSubmit();
    });
    $("#ChooseWebinar_RecordedWebinarId").change(function() {
        if ($(this).val()) {
            $("#ChooseWebinar_UpcomingWebinarId").val("");
        }
        toggleChooseWebinarSubmit();
    });
});

thx

A: 

The input name attribute is cdata, which means any character that can go in an HTML document can go in it. . is certainly allowable.

The only vaguely relevant problem I can think of is that Opera doesn't put ‘previously remembered’ values back in the form (when you enter a page via back/forward but the bfcache is not operational) until the default action on window load, which occurs just after onload. IE puts remembered values in after loading DOM content; the other browsers put them in directly as their elements are parsed. So if you want the hiddenness of the button to be correct as much as possible during the load process you have to do your toggleChooseWebinarSubmit check once immediately, once on document ready and once on a 0-timeout just after onload. (Most people don't bother with all this. Opera's behaviour could maybe be considered a bug.)

Probably not very helpful, sorry. Sounds like it's going to be a tricky debug with such little information...

bobince
Opera? It was IE8 which bugged. Since it seem to work on other IE8 clients, my first thought is that it's an outdated (beta?) version of IE8. I'd to ask the client to give the exact version as it appears in *Help > About* and if necessary to get the latest updates from Windows Update.
BalusC
Yeah, I thought it probably wouldn't be very helpful. :-) I would hope there aren't any IE8 betas still unWindowsUpdated, there were some ghastly bugs in those things. There's also always the possibility of broken browser extensions and filtering proxies messing with the scripts I suppose.
bobince
In that the original question asked 'are dots legal' - direct answer - thx.for sake of history...the browser in question is the release version of 8. To troubleshoot i inserted 'alerts' at each of the branches and asked the user to repeat the steps. Each alert fired where/when it should have. I removed the alerts and it still worked. No other code changed _anywhere. The workstation hadn't been rebooted between when it failed and when it worked. a +1 for a viable explanation to that behavior.
justSteve