I'm experiencing issues with IE9 which is not performing the actions I need when clicking a button that was initially disabled, and re-enabled via javascript.
I have a form (built with perl CGI) which has several buttons. These are all disabled in the actual html, and are being enabled when the form is completely loaded. This is done to avoid users saving the page before it is fully loaded.
In all browsers the buttons appear disabled initially, and get enabled when the page is fully loaded. Also in IE.
Now these re-enabled buttons don't do their work when clicked in IE (tested with IE 9), but they do work as expected in firefox and chrome.
The code for one of these buttons as it appears in the IE developer tools:
<input name="Event_Action" id="syncStream" type="submit" value="Create Sync Stream"/>
The code which creates the button initially disabled:
print $query->submit( -name=>'Event_Action', -value=>$btnCreateSyncStream, -disabled=>'disabled', -id=>'syncStream');
The buttons are being enabled via the onload event of the body tag:
<body onload="enableButtons()">
<form method="post" action="/cgi-bin/pdf/pdf.pl?&pdf_id=1071&release=at7.1.0&pdf_patch_rel_phase=b" enctype="application/x-www-form-urlencoded" onsubmit="return validatePatchNr()" name="MYFORM">
The javascript function enableButtons:
function enableButtons()
{
var buttons = document.getElementsByName("Event_Action");
for (i=0;i<buttons.length;i++)
{
buttons[i].disabled=false;
}
}
Now, when one of these re-enabled buttons is being used, IE seems to reload the page, but the actual action linked to the button is not being executed.
The same page in Chrome and Firefox works correctly. Both of these browsers execute the correct action.
I supsect that not every field on the form is being submitted which causes the Perl script not to recognize the action that is requested, but I'm not sure of that yet.
I tried debugging the issue with the dev tools in IE, but those are not really easy to work with if you're used to firebug.
Anyone has any idea what might be going wrong here? I might be missing something obvious.
Well did you try to use different name of each button ? Usually some browser do not submit name value pair of each button, but some browser does. I Guess you should change the name of each button to be unique and use a hidden field to determine the Action to perform rather than button VALUE.
Related
So I'm troubleshooting an issue in our app and can't figure it out. I haven't written the base code and can only inject CSS and Javascript. There's a very basic span element with an ID, below that is a snippet of Javascript basically saying "if element with ID submitButton is clicked, submit form #createForm". However, on mobile it's broken and the browser is not giving any errors.
<form method="post" action="page.html" id="createForm">
<span id="submitButton">Submit form</span>
</form>
<script>
$("#submitButton").on("click", function (event) {
if (attributeEqualsDisabled($(this).attr('disabled'))) {
return true;
}
$("#submitButton").attr('disabled', true);
$('#createForm').submit();
});
</script>
Now, this works perfectly on desktop browsers, even when using the "display as iphone" mode Chrome has. You can click the button, everything works.
However on mobile safari and when adding the page as a webapp the button no longer works. When you press it the page just scrolls to the top and does nothing. I've checked it out through my Mac and everything seems normal and exactly the same as on desktop. I can even run $("#submitButton").click(); on my iphone through the console and it functions perfectly.
There are no errors or warnings in the console. Does anyone have any suggestions to troubleshoot this? I sadly can't give direct access to the code because everything is on an IP locked server.
Is there any way of seeing exactly what happens when I click the button? I've tried the "Timelines" tab but that shows nothing when I press the button.
This answer by another user fixed it: https://stackoverflow.com/a/3026621/3461722
Thank you to Robin Zigmond for pointing me in the right direction. I was thinking that something was preventing the click event from firing, but it was simply not picking up on it because I needed to track the touchstart event.
The linked answer does mention that a better solution was found by adding cursor:pointer; to the button with CSS, however my element already had that so it obviously didn't work in this case.
Add this function to detect the taps on mobile:
$('#submitButton').bind( "touchstart", function(e){
if (attributeEqualsDisabled($(this).attr('disabled'))) {
return true;
}
$("#submitButton").attr('disabled', true);
$('#createForm').submit();
});
Chrome Extensions have had a Version 2 of their options page since Chrome 40. I tried creating an options V2 page with a button that just has a simple alert:
js
function resetAll() {
alert("Not yet implemented.");
}
document.getElementById("reset-button").onclick = resetAll;
html
<button id="reset-button">Reset All</button>
When I click the button in the options page, nothing happens. I even pulled up the Javascript Debugger to see if my code was actually being run. And it was, but no alert showed up.
If I use Chrome Extension's older options page format, the alert shows up without problem.
Is there no way to create a browser-native alert with OptionsV2?
chrome.extension.getBackgroundPage().alert('Are you sure you want to delete X?');
chrome.extension.getBackgroundPage().confirm('Are you sure you want to delete X?')
I'm having cross platform issues with Firefox and form submissions.
http://pastebin.com/BEFsBd8h
In the example, when the button is disabled and the page I'd directs to another location, firefox does keep the button disabled whereas other browsers do not.
I know I can use an onunload event to remove the disable attribute. But I'm wondering if there's another way. I've also tried by setting autocomplete off but alas it did not work
Reproduce bug:
Use firefox
Disable button
Use sudo-submit
Back button
The test button should still be disabled.
When Firefox traverses history, it will not always reload the page, but often will actually use a cached copy of the page with the same state from where you left it. So if a button was disabled when leaving it, then it will be disabled when "going back" and the page is still cached in the backward-forward-cache (bfcache).
Two options to deal with this:
Implement either pageshow or pagehide events. E.g. you could reset the DOM state in pageshow.
Implement handling of the unload event. This will disable the bfcache entirely, and therefore degrades performance, but is easier to do.
For more information, see the rather old, but still applicable "Using Firefox 1.5 caching" article.
I'm working on a Chrome extension, and want to use prompt() to get input from the user when they click on certain elements. Unfortunately, for some reason, I can't get prompt() or alert() to work when called as an onclick (or in a jQuery $('#something').click(function), which is how I originally ran into this).
To wit, if I use the HTML below as the popup.html for my extension, the first alert shows up, but the second one flashes on the screen and then immediately disappears without any user intervention. And then the extension popup also immediately closes.
<script>
alert("This alert works");
</script>
<input type="button" onclick="alert('This one disappears')" value="Button"/>
Any thoughts on why this might be happening and how to fix it would be greatly appreciated.
Alerts/prompts are not working inside popups (see this bug report for details). You need to find alternate solution (use html form instead).
I have a page with a few hidden fields in it. Those get filled with values by a script (JS/jQuery) when the user has finished selecting a couple of options.
Now, if I click a link on that page, go to the linked page and then hit the back-button, FF and Safari are able to read out the values of the hidden fields. So the function to read out the values seems to be correct (it's not complicated anyway).
But IE (and also Opera, even though I set history.navigationMode to compatible) shows me empty values, even though I can see the correct values in the generated sourcecode of IE.
I also added a test function, to show me the values onunload, which worked fine. But hitting the back-button IE still doesn't "recognize" them.
I have no idea what the problem here is. Anyone?
Thanks!
Actually, Firefox even keeps current values when hitting refresh, while IE resets page to initial values on refresh. I guess this is same stuff. No standards describe what should actually happen here, so you should not rely on how the different browsers choose to handle this scenario.
You are relying on the browser filling the in correct form fields automatically when re-entering a form using the back button. AFAIK, only FF and Safari do this by default. Whether it can be activated in IE and other browsers, I don't know. Anyway, you can't rely on it in the wild.
You may have to work around this using Cookies. You would have to set cookie values onchange or onunload, and read out the cookie values when your page loads.