Following the tutorials for RadAutoCompleteBox control for ASP WebForms, I have the following code:
<telerik:RadAutoCompleteBox SelectMethod="GetUserTags"
runat="server"
ID="tagsAutoCompleteBox"
InputType="Token"
Skin="Metro"
DataValueField="Id"
DataTextField="Value"
Width="200px"
DropDownWidth="200px">
</telerik:RadAutoCompleteBox>
However I can't add any tags, because input is not accessible (clicking in control does nothing). After investigating generated HTML, I see, that inner input has set max-width: 0 in its style.
When I manually delete this style entry in chrome developer tools, it works as expected. Data source is correctly set, entries can be added and read. The only problem then is, that tags are above the input, not on the left:
How to work around this?
Related
I've created a web page with a form using Bootstrap 5. One of the controls on the form is a select box, and I just noticed that it keeps having a gray background. At first, I thought it was just my browser's autocomplete, but upon further investigation, I discovered that select form-control had somehow been assigned read-only.
HTML:
<select name="country" class="form-control " id="country">
...
</select>
CSS, from the Dev Tools highlighting the control:
.form-control:disabled, .form-control:read-only {
background-color: #e9ecef;
opacity: 1;
}
In Dev Tools, .form-control:read-only is highlighted, so that means that it is active. I cannot see anywhere in the HTML that my select has been marked as read-only, and I can't figure out how to find out when that is happening. There's no way that it is marked as read-only on the first render. I can't find anything in my JavaScript that could be changing the state to read-only. I do have JavaScript that populates the select with a value, but when I comment that out, the form-control is still marked as read-only.
I would appreciate any help in figuring out why my select control is marked as read-only, and what to do to prevent that.
You can use MutationObserver to observe changes in the DOM tree (attributes included). See the linked page for example usage.
If you forget to close a HTML-Tag, Chrome will validate your code and try to fix problems like this.
I had a major problem because I forgot a closing Form-Tag, and instead of closing it correctly, Chrome deleted a following form, not the inputs, simply the Form-Tags.
When I looked at the Source Code itself, the Form-Tag was there, but not in the Elements-Tab in the console.
So at first, I thought it must have something to do with some JS deleting this DOM-Node and set a DOM-Breakpoint to find the script.
To cut a long story short, it took me hours to find out, that no JS deleted my form, but Chrome itself thought: There is a missing so I delete some other to fix that...
Is there any possibilty to see if Chrome automatically changes your DOM?
Thank You!
The browser Engine does indeed. They use string replace methods, although it happens internally.
<div>
</div>> // mistake
<div> //missing end tag
<div></div>
---------------------------------------------------
Methods
file=file.stringreplace('>>', '>')
an uneven count will add the missing div just after the next beginning div and conditionally if the missing is not found by the end of the file:
file=file.stringreplace('
<div>', '</div>
<div>')
The Parsing Engine after the missing and broken tags are repaired then parses the file and can then with a positive count set the screens GUI widgets by opening and closing tags as GUI Frames. It does this by adding tokens delimiters to the actual div tags making them easily distinguished from each other.
<div1s>
</div1e>
<div1s>//section columns
<div2s></div2e>
<div2s></div2e>
<div2s></div2e>
</div1e>
<div1s>Footer</div1e>
-----------------------------------------------------
The GUI Frame Tokens
for each "<dive1>"{
FrameCreate(CSS--ATTRIBUTES FROM ASSOCIATIVE ARRAYS--)
//the GUI Frame Widgets VERTICAL SECTIONS
}
//Next it finds the nested divs2 and embeds these into the thir parents above but with embedded Text Widgets also.
FrameTextBoxCreate(--CSS MATED ATTRIBUTES RULES--)
div3 etc------and so on.
In fact it is in the WebView GUI Widget Sets in its customized Mosaic Canvas Widget Sets in Chrome would be where they are repaired.
i honestly don't know alot about IPhones, however i have received a report, and also independently verified, that just before a customer updated his phone, he was able to press the "upload file" button or our webpage, and either choose an existing file, or snap a picture and use that. However immediately after installing the 10.3.1 update, when he presses the exact same button, it goes straight to the camera.
The button looks like this:
<input id="inputFilesButton" type="file" name="files[]" capture="camera" accept="application/image, image/*" style="width: 100%; height: 100%; font-size: 15px;" multiple="">
So my question is, is there anything i can do, whether it is changing the HTML code, or changing a setting in the IPhone?
UPDATE: The same behavior has been duplicated in Safari, Opera and Chrome.
UPDATE2: The same behavior has been duplicated on 7 different IPhones, where this problem occured after the update-.
If you remove the capture attribute, the system won't prefer a camera upload, and will ask where your image is coming from (camera, gallery, etc.).
Here is a fiddle with two upload buttons. The first one has the capture attribute set; the second one does not. The second one should do what you want it to do. Tested on an iPad running 10.3 -- the first button forced a camera upload but the second button did not.
Removing the capture attribute, your button should work:
<input id="inputFilesButton" type="file" name="files[]" accept="application/image, image/*" style="width: 100%; height: 100%; font-size: 15px;" multiple="">
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.
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();
});