I'm having a ton of problems with every version of IE, one of which is that IE7 won't register input in this text input field.
http://www.flightm8.com/redesign
I'm a bit nervous about posting the link since the site looks a mess and doesn't function properly in any version of IE at the moment, and it is still quite a way off being ready for public consumption. But if anyone can shed any light on this particular problem I'd very much appreciate it.
So the question is: What is causing this problem in IE7?
Update: I've also added an additional textfield at the bottom of the page to try and rule out any CSS wierdness that might be causing the problem.
<form method="post" action="nowhere.php">
<input type='text' name='test' value='testing' />
</form>
And I still can't enter any text, or select the text that is in there. I'm wondering now if it's a problem caused by running a standalone version of IE7 and IE6.
thanks
-t
the function causing problem is this one :
function modalAlert
the call that need to be debugged is this one :
modalAlert("NO SELECTIONS");
in
function findRoutes
the line that bug is :
$("#dialog").css("top", dTop);
first, you should avoid iframes when you can, why don't you do :
var message = $('<div></div>').load('/modal/"+modalpage);
instead of crappy code like this :
var iframe = "<iframe id='modal_frame' width='533' height='292' src='/modal/"+modalpage+"' >You didn't give me any information</iframe>"
If you don't need iframes, don't use them !
$('body').append(message);
I have IE7 on win xp (native), I was able to enter text but after a freeze (when you add all those markers), then when entering text and clicking on "find routes", there's a bug that i just explained to you ...
I would imagine it is because the input box doesn't have a 'name' field, which is used when posting form data.
Related
Im trying to install tinymce to use with my text editor to allow the user to have a text box just like the stack overflow one. I cant get it to display though
ive put this in the head of my index file
<script src='https://cloud.tinymce.com/stable/tinymce.min.js'></script>
<script src='https:https://cloud.tinymce.com/stable/tinymce.min.js'>
</script>
<script src="//tinymce.cachefly.net/4.1/tinymce.min.js"></script>
<script>
tinymce.init({selector:'infotextarea'});
</script>
then in my info page ive put
<textarea id="infotextarea">Your content here.
</textarea>
can anyone explain why its not displaying
It may be that at the time you run the tinymce.init function, it is not yet rendered and there is no textarea in the DOM.
Try debugging your code on the following line:
<script>
debugger;
tinymce.init({selector:'infotextarea'});
</script>
When the web's execution has stopped on that line, in the development console of your browser type the following:
$('#infotextarea').length
If the size is greater than 0, textarea exists at that moment and it is another problem, but if it shows 0 is that you have not yet created that view, this will help us get more information about your problem.
If you want to target a <textarea> by ID you need to use a valid CSS selector.
selector: "#infotextarea"
(note the # at the beginning of the string)
I would also note you appear to be loading TinyMCE 3 separate times - I have no idea why you would need to do that - loading it once should be sufficient
Its not a perfect answer to my question, but i used ckeditor and it worked perfectly.
I must have a mistake somewhere that i or my team could not find with tinymce
I am currently having an issue with Angular.X (Tested with A5 & A6). It appears when using a "Select" within the html, Internet Explorer doesn't bind appropriately with ngModel. I've tested with Chrome and Edge and they work fine, When trying to use this combination in edge- the select never gets set as its default value (The value that is assigned within the model/property its bound to). So the page will load with empty values in the select. I've tried searching but have not had any luck finding an answer how to fix this. 9/10 of the posts I find when searching for this are related to AngularJS. Which always makes troubleshooting fun!
Here is a bit of the code as to how I am doing this:
HTML:
// The repeater is up top somewhere and looks like this:
// <tr *ngFor="let i of this.imgArr">
<td class="ImageCell">
<select [disabled]="this.ApplyingChanges" [(ngModel)]="i.ImageType" class="form-control" (change)="this.ChangeInput(i)">
<option>Part</option>
<option>Model</option>
</select>
</td>
TS Class:
export class PartImage{
public ImageType = 'Part';
The above code is broken up to show what matters.
Thanks for the help in advance!
Sorry I actually resolved this.
After tinkering around, I discovered: With Edge and Chrome, an "option" is not required to have the attribute "value" and uses the label by default. With Internet Explorer this is not true and requires that attribute (Or ngValue) to work correctly.
In our MVC5 project there is a page where user can check multiple assets.
Each asset is represeneted by checkbox and name.
When there are a lot of assets (about 800-1000) Chrome getting extremely slow. It's even sometimes show message that "page is unresponsible".
It looks like this:
- page is partially rendered and stucked on DIV with checkboxes
- then there is delay 30-40-50 sec. Sometimes error message
- DIV with checkboxes rendered and rest of the page rendered too
In FF and IE it's ok.
Thanks in advance
I agree that it's not a good user experience, but at the current stage I need to solve this problem.
Here is markup (this div is 4 level nested):
<div class="list">
#for (int i = 0; i < Model.Items.Count; i++)
{
<text>
#{var cid = Guid.NewGuid().ToString();}
#Html.HiddenFor(m => Model.Items[i].Id)
#Html.CheckBoxFor(m => Model.Items[i].Selected, new { id = cid })
<label for="#cid">#Trakopolis.WebSite.AppHelper.GetLocalizedString(Model.Items[i].Name)</label><br />
</text>
}
</div>
You could try to use javascript for this where everything is in plain text with data attributes and on click, input element is temporarily added, the input element takes the input, sends it to the server (or saves it in indexeddb for async using a service worker) and removes itself or waits for next input.
<td id=“unique-id1” data-url=“/action” data-name=“InputName”>data</td>
Same problem with Safari, I suspect a webkit bug. Any page with hundreds or thousands of input fields will be very very slow to navigate or edit.
See Why does Safari Mobile have trouble handling many input fields on iOS 8
We have a page with some tables with 300 rows, each row has several cells and each cell is editable (input).
Workaround given in link above works nicely.
Looks like Chrome not uses closing tags for checkboxes dropdown markup for and <br> that is somehow forces additional browser internal checks and as result slow page rendering in comparison to IE and FF browsers(that are using closing tags). To avoid Chrome slow loading because of <br /> tags you may use opening and closing <div> instead and speed up page a bit, but I'm not sure whether <input> elements may be replaced somehow.
Thanks for spending time to read this
I have a form where is call a JS function to copy the html content of a DIV to a hidden form field so that I can submit this with the form. It works fine on desktop webkit broswers and also on mobile safari on iPad. However when I run the application in fullscreen mode (by saving a shortcut on home screen), this does not work.
Here's my code
JS function:
function update_script_in()//copies scripts and submits the form
{
$("#script_in").html($("#scriptContent").html());
$('#ResiForm').submit();
}
form submission:
<input type=submit value="Submit" onclick="update_script_in()">
Thanks for your help
This is quite old, but after googling around to solve the same issue for me, I have not found a solution. Looks like some weird behaviour from iPad (easily reproducible, no way to fix, at least that I found): the target input field gets changed indeed, but the posted value is the original one (???)
So just in case a workaround is useful to somebody, instead of applying the changes from the contenteditable div on form submit, I apply the changes whenever the div is changed (no on change event for contenteditable divs, so really it is done on blur event):
<div id="editor_inline_core_body" class="inputbox editor-inline" contenteditable>[initial value here]</div>
<input type="hidden" id="jform_core_body" name="jform[core_body]" value="[ initial value here]" />
<script>
jQuery('#editor_inline_core_body').blur(function() {
var value = jQuery('#editor_inline_core_body').html();
jQuery('#jform_core_body').val(value);
return true;
});
</script>
Less efficient, but at least it works. If you want a bit more of efficiency, you can check old and new values using also focus event, but at least I do not think it is a big deal or worth the added complexity.
The site I am editing has a search form. For the record, there are several other forms on the site, contact and the like. This is the only one with an issue.
Upon submission of the form, SOME of the styling is lost in IE9 (possibly other versions of IE, haven't tested that yet). Primarily, the margins and colors set in html and body appear to have been lost. Menus, banner, text, etc all appear to retain styles. All styles are on one sheet, that are used here...
Any helpful advice?
Here is the contents of the search page and the php used to check for the form, if that helps, and the css that I think is lost.
EDIT: The page is a search page, with almost nothing on it. A search reloads the same page, while displaying results from the search function. Thus, the same embedded sheets should be embedded, the same html is displayed as far as I can see... if this helps the discussion any. Still sifting to find some type of error. IE dev tools also seem to indicate that this error occurs in previous versions of IE as well, when viewed in IE7-8...
THE HTML:
<div id="search">
<br />
<div style="float:right;font-size:.8em;">
<form name="form_sidesearch" action="search.html" method="post">
<input type="hidden" name="action" value="search" />
<input type="text" name="search_value" value="<?php echo $systems_primary->search_value ?>" />
<input type="submit" name="submit_search" value="Search Website" />
</form> <br />
</div>
</div>
<?php echo stripslashes($search_results);
THE PHP:
<?php
// -- Begin Search --------------------------------------------------------------------------------------
if($_REQUEST["action"] === "search")
{
if(strlen($_REQUEST["pg"]) <= 0)
{
$_REQUEST["pg"] = 1;
}
$search_results = $systems_primary->search_website("index",urldecode($_REQUEST["search_value"]),"<div class=\"listing ui-corner-all\">{ENTRY_TITLE}{ENTRY_CONTENT} ...read more</div><br /><br />",345,"all",10,$_REQUEST["pg"]);
}
// -- End Search ----------------------------------------------------------------------------------------
?>
THE LOST CSS (could be more):
html {
background-color:#F6E6C8;
font-size:16px;
font-family:Helvetica;
}
body {
width:1027px;
margin:0 auto;
background-color:#ffffff;
font-family: arial, 'times new roman', sans-serif;
}
Elaboration: The actual thing that happens is that the page content as a whole is shifted left and remains left aligned instead of using the auto margins to stay centered. Additionally, the html background color is lost. The styles for the search fields are also lost or ignored. Not sure what else might be altered.
Typically when styling is lost after submitting a form, especially when it's an Ajax operation and not a full page reload, it's because there was some styling applied using JavaScript or jQuery that did not get reapplied when the updated portion of the page was reloaded. This could involve additional elements being created, or it could involve CSS classes being added to 1 or more elements.
This is especially likely to happen with the styling of HTML form elements, because in some cases heavy styling of certain form elements can only be done with the help of JavaScript or jQuery.
In such cases, identify the JavaScript or jQuery that styled the relevant content when the page first loaded, and then reapply it after the page has been updated (after an Ajax call has completed successfully, or after the browser has reloaded the page or loaded a new page).
Failing that, compare the HTML for the page before and after and see what changed. There may be a CSS class on the body tag or a container class that's not getting consistently set. If a new page is loaded, a different set of CSS files may be getting downloaded, or there may be an embedded style sheet that one page has but another does not.
Failing that, verify that the HTML and CSS are valid. Some browsers are more forgiving than others when rendering invalid code. What may seem like a browser bug could be caused by bad code.
If all of that turns up nothing and it seems increasingly likely that the problem is caused by an obscure browser bug, then reduce the code to the simplest possible state in which the problem can be consistently reproduced, and try to identify more clearly exactly what the nature of the bug is. This will make it easier to search for possible fixes and to ask for help. And in the course of reducing the code, if the problem suddenly disappears, the last code removed may turn out to be at least partly responsible for the problem.
Conversely, when it seems like there's no rhyme or reason to a problem, it's sometimes helpful to reimplement the code from scratch, to see if the problem still occurs. If the problem starts to occur at some point while writing the code, then likewise the last code that was added may be at least partly responsible for the problem.
You can do something like this...
$('#yourForm").on('submit',function(e){
$(this).css({
// reasign all the atributes you lost
});
e.preventDefault();
});