I have several users trying to submit a webform. But i'm getting reports that when they click on a select dropdown menu or start to scroll through the options it causing the browser to crash - Internet explorer has stopped responding. The user then refreshes the page to try again but then faced with the same issue.
This is only related to IE 11 and this happens randomly - sometimes the select option works and then they click on another select and it crashes again.
IE11 version: 11.648.17134.0
Windows 10
jquery-3.3.1.min.js
Please bear in mind some users will not have access rights to their browser settings.
Here a simple select menu:
<select name="test" id="test">
<option value="Yes">Yes</option>
<option value="No">No</option>
</select>
I read that adding a resize option to the list to 0 or 1 might resolve this issue. So i added a jquery to modify them all onload:
$( document ).ready(function() {
setTimeout(
function()
{
$("select").attr("size", "1")
}, 10);
});
But this didn't help
Related
I am here asking how is it possible for my chrome extension to be able to "survive" throughout the user refreshing the page and changing page after selecting a feature.
For an example let's use a rather generic background color changing setting which changes the background color of a desired site. Once ticking the enable box and having the background changed to the option selected, it does not stay persistent after changing page or refreshing. I am here asking if someone could possibly help me with some sort of helpful resources which are more helpful than the developer.chrome site.
EDIT: for much better example of my question which is my bad. If anyone of you are aware of such extensions like "BetterTTV" for Twitch, it has a menu of options. One of these options is the "night" option which mentioned prior turns the entire site to "night colors" such as whites to black and black text to light. This option once enabled is seen through the entire site and even once Chrome is closed is still enabled to be producing changes next time opened. If i am correct in understanding what has been said, using Chrome storage will preserve such actions enabled by the user to be produced on the page till disabled.
Thank you.
A content script can survive for the same time that a webpage remains in the tab (i.e. not through refresh, or navigating to a new page). You can not make this longer. A background script can exist for the time that Chrome is running from starting Chrome through exiting. If you want to save settings, you can use chrome.storage, or store the setting in the background page. You can then read the settings, or get them from the background page, when your content script starts again when the page is refreshed, or the user navigates to a new page. Using chrome.storage will allow you to persist the option until turned off. Using chrome.storage, even if Chrome is exited and restarted later, the option information will still be available. If you just store the data in a variable in the background page, it will not persist through exiting and restarting Chrome.
If you are changing a setting in a content script it will live only as long as the content script unless you get the information somewhere will it will persist longer. That means chrome.storage or messaging the information to a background script. Either way, if you want to have the setting active when the content script next runs (refresh, navigating) you will have to get the setting back (e.g. reading from chrome.storage or receiving a message from a background script).
In general, changing options in the content script is, probably, not a good idea. It is uncommon for such to be done in the content script. On the other hand, depending on what you are doing, changing some of your extension's options in a content script may be the most appropriate.
How best to organize this depends on what you are doing. To go further really requires more information from you (e.g. code that shows what you are doing). There are many examples around of having settings persist, although usually not changed from a content script. Settings are mostly changed from options pages, popups, etc.
If your function is as simple as "ticking the enable box and having the background changed to the option selected", having the selection take place in the content script is not a good idea. In that case, you should have a browser_action button which is either a toggle, or that brings up a popup where a checkbox could be ticked (if you have multiple options). The background script would then inject the content script using chrome.tabs.executeScript() only when the feature was enabled.
Update:
Based on the new information you have added to your question, it sounds like you should use a popup which will allow you to have multiple options, or a list of sites on which your add-on is enabled. If you are looking for an example, you can take a look at the Chrome developer options page example. You can have that as a popup with a `browser_action button in addition to being an options page by adding the following to your manifest.json
"browser_action": {
"default_icon": {
"48": "myIcon.png"
},
"default_title": "Show panel",
"default_popup": "options.html"
},
If interested, my answer to this question shows using a single page as both an options page and popup. It shows how to get the data from the options page into chrome.storage and read it back. It is a bit more complicated than potentially desired as it shows four slightly different methods of communicating the information from the popup to a background page. It is tested and working in both Chrome and Firefox.
Here is an example of reading data (useDirect and emailAddress) from chrome.storage and placing the information in the DOM (to show the current value on an options page/popup):
// Restores select box and input using the preferences
// stored in chrome.storage.
function useStoredOptionsForDisplayInDOM() {
chrome.storage.local.get({
useDirect: 0,
emailAddress: '',
enabled: false
}, function(items) {
//Store retrieved options as the selected values in the DOM
document.getElementById('useDirect').value = items.useDirect;
document.getElementById('email').value = items.emailAddress;
document.getElementById('enabled').checked = items.enabled;
});
}
This is how those same values are stored in chrome.storage:
function saveOptions() {
let useDirectValue = document.getElementById('useDirect').value;
useDirectValue = +useDirectValue; //Force to number, not a string
let email = document.getElementById('email').value;
let functionEnabled = document.getElementById('enabled').checked;
chrome.storage.local.set({
useDirect: useDirectValue,
emailAddress: email,
enabled: functionEnabled
});
}
And the <body> of the HTML:
<body>
<div id="optionsArea">
Use direct method:
<select id="useDirect">
<option value="0">Option 0</option>
<option value="1">Option 1</option>
<option value="2">Option 2</option>
<option value="3">option 3</option>
</select>
<div>Email:
<input id="email"></input>
</div>
<label>
<input type="checkbox" id="enabled">
Enable functionality.
</label>
</div>
<script src="options.js"></script>
</body>
As you can infer from the title, this is an interesting & frustrating bug. I have a normal select element in an Angular partial with the following code:
<select ng-options="availweek.weekNumber as availweek.weekNumber for availweek in availableWeeks | orderBy: 'weekNumber':'reverse'"
ng-model="selectedWeek.weekNumber"
ng-change="viewPrevWeek(selectedWeek.weekNumber)"
style="color: black">
</select>
This element displays a list of numbers (representing weeks) and triggers the viewPrevWeek function when one is changed. That function is below- it just passes the week and reloads the partial to reflect data relevant to the selected week:
$scope.viewPrevWeek = function (week) {
if (week <= $scope.totalWeeksAvailable) {
$localStorage.active_week = week;
$state.reload();
}
}
My issue is that, on iOS 10 only, if a user changes the selected week via the dropdown (thus triggering viewPrevWeek), the dropdown will then pop up on any click of any button in the rest of the app.
This is precisely as annoying as it sounds- so if a user selects a something in the dropdown and decides to navigate to a new page, the dropdown reappears when clicking to expand the nav. The behavior is as if the dropdown retains focus after selection, so any click in the app also registers as a click on the dropdown, which causes the selector to open.
This only occurs if the week is actually changed- if the user opens the dropdown and selects the choice that was defaulted at page load, this doesn't happen.
I'm at a loss for how to get to the bottom of this- it doesn't occur on Android phones, nor when I use Chrome or other dev tools to force a phone screen resolution on desktop. It occurs on both Safari and Chrome in iOS 10, and doesn't occur in either browser in iOS 9 - so I'm pretty sure this is related to changes in iOS 10.
Not sure if you've solved this one yet, but we had the same problem and came up with a fix.
It seems that iOS 10 has something funky going on in the time between the native dropdown closing and when the code in your ng-change method gets fired. We found that the browser acted like the dropdown was still open and would trigger again when clicking any link, despite our ng-change event firing correctly.
We drew some inspiration from this thread: https://stackoverflow.com/a/24056865/542124 and set a timeout inside our method. This allows for iOS to finish closing the native dropdown UI, and finish whatever else it needs to do, before executing our code. In your example, this is how we would approach it;
$scope.viewPrevWeek = function (week) {
if (week <= $scope.totalWeeksAvailable) {
$timeout(function() {
$localStorage.active_week = week;
$state.reload();
}, 1000);
}
}
We'll give it a second to finish, show some sort of loading spinner to signify to the user that something is happening, and that should allow enough time to pass to resolve the issue.
Given a simple select list.
<select>
<option>Test 1</option>
<option>Test 2</option>
<option>Test 3</option>
<option>Test 4</option>
</select>
Running Example: http://jsfiddle.net/gbdvn2ht/
Open Page in Safari (8.0.8 or earlier I presume, it works as expected in OSX 10.11)
Observe that clicking quickly over and over on the select list opens the select list and selects the first item.
Focus on another window (I used a terminal but it doesn't matter)
While focused on the other window click back into the Safari tab but make sure you click directly on the select and continue clicking quickly.
Observe that the select initial opens, closes, and then stops responding. A page refresh of the page is the only way to make it work again. Clicking on it no longer opens the select list.
Strange right?
Given the fact that the newest Safari doesn't present the problem I can assume it's a Safari bug. However, I still need to support this version of the browser. Any ideas on a workaround would be greatly appreciated.
I do not have access to that version of Safari, but have you tried using a jquery plugin to override the drop down ? I thought it would be worth a shot.
I've updated the jsfiddle for you to try.
http://jsfiddle.net/gbdvn2ht/1/
The plugin I tried was Select2 (https://select2.github.io/examples.html)
$("#select").select2({
minimumResultsForSearch: Infinity
});
This is a strange bug that occurs on the iPhone 5 when navigating back to a previous page.
Here's the steps to reproduce the bug on an iPhone 5:
Select a menu option that directs to a new page
From the new page press the browser back button
Try and navigate to the same page again using the same menu
An example page to try this on is here. On this page, select 'Javascript Tutorials' from the first menu on the page. Then follow steps above...
In my situation there is no go button to follow the link (like the second menu on the example page). The option is followed when clicked. The problem with this is that because the page you returned from is selected in the menu, you are unable to navigate to it. You cant re-select it.
My question: Is this a known iOS 7 bug? And is there a solution? My search has come up empty so far.
My JS code selects the first option when the menu is generated on page load. And as said, this bug only occurs on the iPhone.
This is not an iOS 7/iPhone 5 bug.
I can recreate it in Chrome on Windows 7.
As you said,
"because the page you returned from is selected in the menu,
you are unable to navigate to it"
The menu is pre-selected because of autocomplete behavior
When you press browser "back" in step 2 (versus page refresh), browser remembers the state you left the select in
https://stackoverflow.com/a/2699400/1175496
When you re-select an option that is already selected
You haven't changed anything; so the change event doesn't fire
Scripts listening for that event (as with the onChange attribute in your example) won't send you to the page
I fix this by putting autocomplete="off" attribute on the form element containing your select;
this prevents number 1, which prevents number 2.
I have also posted this question to Codiqa support some time ago, so I am not trying to turn stackoverflow into a Codiqa support center, just know alot of the guys supporting Codiqa are on here, but let me know if I am not allowed to be asking for support for a product on this site...
That aside, I have a select box with size="5" attribute that displays a max of 5 options that are populated via for loop with information from a database. The idea is for this select box to act as a listbox to show the user said information in the select box. However, Codiqa or maybe jquery mobile in general, converts any select box into a button that only can view the content when clicked on. This adds an extra and unnecessary step for my client in this instance. How can I force Codiqa or jquery mobile to honor my size attribute, so the user can see the populated information without having to click to view?
Thank you!
Chrome Browser
Codiqa
Creator of Codiqa here. This is jQuery Mobile behavior that you can disable by telling it to not enhance that form element:
<label for="foo">
<select name="foo" id="foo" size="5" data-role="none">
<option value="a">A</option>
<option value="b">B</option>
<option value="c">C</option>
</select>
We don't have a way to do this right inside of Codiqa yet, but it would be easy enough to add.
Working example: http://jsfiddle.net/bagz8/
You can programatically force select to open itself when page is available:
$(document).on('pagebeforeshow', '#index', function(){
$( "#select-choice-4" ).selectmenu( "open" );
});
This would be a workaround.
EDIT :
Then force jQuery Mobile not to style select boxes. There are several solutions but this one is probably the best: http://jsfiddle.net/bagz8/1/
$(document).bind('mobileinit',function(){
$.mobile.page.prototype.options.keepNative = "select";
});
Warning, mobileinit event MUST be initialized before jQuery Mobile is loaded. You can see it in my example.
There are several other solutions of enhancement prevention and you can find theme here, just look for a chapter: Methods of markup enhancement prevention