When I click backcolor button/change background color, there is an error msg "Invalid argument", does anyone know how to figure out this issue? thanks~
Btw: All IE versions
i find ..ie 9 browser
NicEdit background this.ne.nicCommand('hiliteColor',c) ==>this.ne.nicCommand('backColor',c)
The execCommand method is a method of the document, not the Range. Also, hilitecolor only works in Firefox, so you should fall back to using backcolor in WebKit and Opera.
Related
I've this problem: I've connected a bluetooth reader scanner to my iPad as emulator keyboard, when I try to read a barcode with focus on a textarea, it seems to break the words randomly.
This only on iPad and iPhone, on all browsers: Firefox, Chrome, Safari
but not on Android. But I've to work on Ipad.
Output Reading on pc (value of textarea):
FF0034DC3214E20336C30C37
FF0034DC3214E20236C30C37
FF0034DC321540C336C30C03
FF0034DC3214A53036C30C06
FF0034DC3215804936C30C32
FF0034DC321584F936C30C35
FF0034DC3215A45336C30C03
FF0034DC321540C536C30C35
FF0034DC321B2CB336C30C03
FF0034DC3214A4D936C30C34
FF0034DC321540C436C30C36
FF0034DC3215907136C30C35
Output reading on iPad:
FF0034D
C3214E20
336C30C37
FF0034DC3214E20236C30C37
FF00
34DC32
1540C336C30C03
FF0034DC
3214A53036C30C06
FF00
34DC3215804936C30C32
FF0034DC321584F936C30C35
FF0034DC
3215A45336C30C03
FF0034DC321540C536C30C35FF0034DC321B2CB336C30C03FF0034DC3214A4D936C30C34FF0034DC321540C436C30C36FF0034DC3215907136C30C35
The strange things is that on some website it works!
For example on "https://jsfiddle.net/", if I put cursor in tab "html" and begin the readings with scanner, it works fine (on the html of this tab there is a textarea and when you write something, a span is created.
I don't understand how it works).
Anyone had never have this problems before?
I am working on a hybrid HTML5/iOS app that uses the Safari Webview. We are using AirPrint to allow the user print the contents of the webview. The problem I am having is that after the print dialog is opened, the print styles are taking affect on the screen, and even after printing is complete or canceled do not go away. This does not happen in our Windows or Android versions of the app, which use CEF and Android System Webview respectively. Print styles in those versions of the application are only applied to the print out, as expected.
Anyone have any experience using AirPrint with Safari Webview that could shed some light on a solution? I have considered just adding/removing the link tag containing the CSS with javascript before and after printing, but that feels hacky, and doesn't answer the curious question of why print styles are being applied to the screen.
Any help appreciated! Sorry there is no real way to attach code to this!
Yes, this is indeed a not expected behaviour. However, we can try to solve this using JavaScript.
Theory: When the print is done, let's reload the stylesheets. The browser will paint the page again and hopefully using screen definitions.
Practice: As we don't have a JavaScript callback after printing, you could try reload your stylesheets using the window.onfocus event, as follows:
function updateStylesheets(){
var links = document.getElementsByTagName("link");
for (var x in links) {
var link = links[x];
if (link.getAttribute("type").indexOf("css") > -1) {
link.href = link.href + "?id=" + new Date().getMilliseconds();
}
}
}
window.onfocus = updateStylesheets;
In detail, it grabs all <link> tags and appends a random number after, forcing a reload on the stylesheets.
Please let me know if that worked, I'd be glad to help.
I have a strange error occurring only on safari for iPads. I've added a youtube iframe element to the page that looks like this.
<iframe width="560" height="315" src="http://www.youtube.com/embed/dDAB35SYIr0?rel=0" frameborder="0" allowfullscreen></iframe>
As you can see I say the source is http and my site is http as well. Now on iPad Safari I get this console error message
Blocked a frame with origin "https://www.youtube.com" from accessing a
frame with origin "http://example.com". The frame requesting access
has a protocol of "https", the frame being accessed has a protocol of
"http". Protocols must match.
I think this is weird for two reasons
1. I specifically say "use http"
2. It works on other devices
Now if I change the protocol to https (now I'm on a https site as well) and try this, I get this error instead
Blocked a frame with origin "https://www.youtube.com" from accessing a
frame with origin "https://www.example.com". Protocols, domains, and ports
must match.
All errors references the html5player.js file.
How can I solve this?
Thanks for your help
Ok, so it seems webkit on IPad has a bug, a weird one. I read it here -> https://tmpworldwide.github.io/bugs/ios-tappy-bug.html
I'll quote a bit of it
Applying the :active pseudo-class to a universal selector (*) and including a property of -webkit-tap-highlight-color seems to be the culprit.
*:active {
-webkit-tap-highlight-color: tomato;
}
Now, here is the strange part. The bug is only triggered when the above CSS block is present and there is an input element present on the page with a type attribute value of "search". I know, crazy, right?
Another oddity here is that when you apply focus to the search input, type something in, and then attempt to play video, it will then work.
The solution for now is to change to input type="search" to input type="text".
I have a dialog page that's saving the address and port of a server in localStorage:
localStorage.SERVER['address'] = address;
localStorage.SERVER['port'] = port;
I've cut my subsequent request down to just console logging the data in localStorage to check things are working.
$("#login_submit").click(function(event) {
event.preventDefault();
console.log(localStorage.SERVER['address'] + ' ' + localStorage.SERVER['port']);
}
What's happening though is that this executes fine when I submit the form without anything in localStorage (I get 'undefined undefined'). However after i've saved some values in the localStorage SERVER object the form reverts to behaving as normal and tries to open
http://mydomain/?username=&password=
and doesn't log anything to the console.
Take a look at this jsFiddle example: http://jsfiddle.net/Gajotres/J9NTr/, I made it for my other ARTICLE, or it can be found HERE.
Basically localStorage data can be added/modified at any time.
Try to access them like this, this example works on desktop browsers, android and iOS devices.
localStorage.firstname="Dragan";
localStorage.lastname="Gaic";
A PDF file is generated on server side and pushed to client end for download. While the download works in all browsers on windows , fails on IPAD.
Please advise.
Specification : OS 6, Safari 6.1 , Chrome 23.0.1271.100
Please note: In this application pdf is not downloaded on to a new url (NO REDIRECTION).
General behavior: IPad browser (safari / chrome) does not support the download window, hence its expected to open the pdf and provides option to view in pdf compatible apps. Which is not currently happening.
When i debug the below servlet action code for download, the pdf file is successfully generated on server but browser on Ipad does not show :-(
Code sample :
/** Setting response Header **/
response.setHeader("Content-Type", "application/pdf");
response.setHeader("Content-Disposition", "attachment;filename=sample.pdf");
response.setHeader("Connection", "close");
response.setHeader("Cache-Control","cache");
response.setHeader("Pragma","cache");
response.setDateHeader ("Expires", dt.getTime() + 100000);
/** Writing to output **/
InputStream stream = info.getInputStream();
OutputStream os = response.getOutputStream();
try {
response.setContentType(contentType);
copy(stream, response.getOutputStream());
}
finally {
if (stream != null) {
stream.close();
}
}
After testing, the download action code pasted above appeared to be working fine as the issue was BROWSER specific.
Andriod Tablet - Firefox browser downloads the pdf onto pop up window.
IPad : Safari - FIX: Forced the content to open up in a new tab, something like this :
window.open(print_url);
where print_url is the baseurl+action.do+additional_parameter.
To display a pdf instead of asking the browser to save it, use "inline" instead of "attachment".
response.setHeader("Content-Disposition", "inline;filename=sample.pdf");
Also, you're setting content type twice, once in the header and once using setContentType().
I'm not sure if those two headers interact or cancel each other out, so can't say for sure that it's a source of error, but it seems like something to consider changing.