The following needs to remove url(' portion of string, previously returned from .css('background-image') on an element object in the DOM, which works perfectly well in Firefox, but not in Chrome.
// example value of artworkURL: url('http://somewebsite/picture.jpg')
artworkURL = artworkURL.replace(/url\(\'/g,'');
I discovered this was because Chrome removes the '' from url('picture.jpg') however, removing \' from the regular expression causes Firefox to then break, because Firefox replaced '' with "" but still understands the regular expression. Even the removal of parenthesis in the CSS causes Firefox to render "" back in.
How do I keep both browsers and their various compliance happy?
Try:
artworkURL = artworkURL.replace(/url\(['"]?/g,'');
This will remove the ' if it it present, and even takes into account browsers that might use " instead. A similar regex can be used for removing the end:
artworkURL = artworkURL.replace(/['"]?)/g,'');
Related
I've run into an issue of regex match not evaluating in Internet Explorer and in Firefox. It works fine in Chrome and Opera. I know Chrome is generally much more tolerant of mistakes so I suspect I've dropped the ball somewhere along the way - yet none of the online evaluation tools seem to find any errors in my expression. I'm sorry that it's such a convoluted expression but hopefully something will be easily obvious as the culprit. The expression is as follows:
keyData = data.match(/\w+\u0009\w+\u0009[\u0009]?\w+\u0009([-]?\w+|%%)[#]?\u0009([-]?\w+|%%)[#]?\u0009([-]?\w+|%%)[#]?(\u0009([-]?\w+|%%)[#]?)?(\u0009([-]?\w+|%%)[#]?)?(\u0009([-]?\w+|%%)[#]?)?\u0009\u0009\/\//g);
'data' is a text file which I am parsing with no errors. I wont post the whole file here but what I am hoping to match is something such as the following:
10 Q 1 0439 0419 -1 // CYRILLIC SMALL LETTER SHORT I, CYRILLIC CAPITAL LETTER SHORT I, <none>
I believe that when I post the string here it removes the 'u0009' characters so if you'd like to see one of the full files, I've linked one here. If there is anything more I can clarify, please let me know!
Edit:
My goal in this post is understanding not only why this is failing, but also if this expression well-formatted. After further review, it seems that it's an issue with how Internet Explorer and Firefox parse the text file. They seem to strip out the tabs and replace them with spaces. I tried to update the expression and it matches with no problems in an online validator but it still fails in IE/FF.
Edit 2
I have since updated my expression to a clearer form taking into account feedback. The issue still is persisting in IE and Firefox. It seems to be an issue with the string itself. IE won't let me match more than a single character, no matter what my expression is. For example, if the character string of the file is KEYBOARD and I try to match with /\w+/, it will just return K.
/[0-9](\w)?(\t+|\s+)\w+(\t+|\s+)[0-9](\t+|\s+)(-1|\w+#?|%%)(\t+|\s+)(-1|\w+#?|%%)(\t+|\s+)(-1|\w+#?|%%)((\t+|\s+)(-1|\w+#?|%%))?((\t+|\s+)(-1|\w+#?|%%))?((\t+|\s+)(-1|\w+#?|%%))?(\t+|\s+)\/\//g
After poking around with my regex for a while, I suspected something was wrong with the way IE was actually reading the text file as compared to Chrome. Specifically, if I had the string KEYBOARDwithin the text file and I tried to match it using /\w+/, it would simply return K in IE but in Chrome it would match the whole string KEYBOARD. I suspected IE was inserting some dead space between characters so I stepped through the first few characters of the file and printed their unicode equivalent.
for (i = 0; i < 30; i++) {
console.log(data.charCodeAt(i) + ' ' + data[i]);
}
This confirmed my suspicion and I saw u0000 pop up between each character. I'm not sure why there are NULL characters between each character but to resolve my issue I simply performed:
data = data.replace(/\u0000+/g, '');
This completely resolved my issue and I was able to parse my string like normal using the expression:
keyData = data.match(/[0-9](\w)?(\t+|\s+)\w+(\t+|\s+)[0-9](\t+|\s+)(-1|\w+#?|%%)(\t+|\s+)(-1|\w+#?|%%)(\t+|\s+)(-1|\w+#?|%%)((\t+|\s+)(-1|\w+#?|%%))?((\t+|\s+)(-1|\w+#?|%%))?((\t+|\s+)(-1|\w+#?|%%))?(\t+|\s+)\/\//g);
I am noticing some very strange behavior in firefox and I'm wondering if anyone has a strategy for how to normalize or work around this behavior.
Specifically if you provide firefox a basic anchor containing html entities it will unescape those entities, fail to re-escape them and hand you back invalid html.
For example firefox mishandles the following url:
My Original Link
If this url is parsed by firefox it will unescape the ><" and start handling a url like:
My Original Link
This same operation appears to work fine elsewhere, even safari and edge.
I tried quite a few different ways of handing the html to firefox to avoid this problem. Tried manually invoking the parser, tried setting innerHTML, tried jQuery html(), tried giving jQuery constructor a giant string, etc. All methods produced the same broken result.
See a fiddle here:
https://jsfiddle.net/kamelkev/hfd2b6sn/
I am a little mystified by how broken this handling seems to be. There must be a way to work around this issue, but I can't seem to find a way.
My application is an html manipulation tool, so I typically normalize around issues like this by dropping down to XML and handling the problems there before persisting to a dumb key-value store, but in this particular case the <> characters are preventing me from processing this document as XML.
Ideas?
A < or a > is valid inside of an attribute value, unescaped. It's not best practice, but it is valid.
What's happening is that Firefox is parsing the original HTML and making elements out of it. At that point, the original HTML no longer exists. When you call .outerHTML, the HTML is reconstructed from the element.
Firefox then generates it using a different set of rules than Chrome does.
It isn't clear what exactly you need to do this for... really you should edit the DOM and export the HTML for the whole DOM when done. Constantly re-interpreting HTML isn't necessary.
The > and < are unescaped when the parser parses the source to construct the DOM. When you serialize an element back to a string, you are not guaranteed to obtain the same text as the source.
In this case, innerHTML and outerHTML use the HTML fragment serialization algorithm, which escapes attribute values using attribute mode:
Escaping a string (for the purposes of the algorithm above) consists
of running the following steps:
Replace any occurrence of the "&" character by the string "&".
Replace any occurrences of the U+00A0 NO-BREAK SPACE character by the string " ".
If the algorithm was invoked in the attribute mode, replace any occurrences of the """ character by the string """.
If the algorithm was not invoked in the attribute mode, replace any occurrences of the "<" character by the string "<", and any
occurrences of the ">" character by the string ">".
That's why " is escaped to ", but < and > remain.
This is OK, because < and > are allowed in HTML double-quoted attribute values:
U+0022 QUOTATION MARK ("): Switch to the after attribute value (quoted) state.
U+0026 AMPERSAND (&): Switch to the character reference in attribute value state [...]
U+0000 NULL: Parse error [...]
EOF: Parse error [...]
Anything else: Append the current input character to the current attribute's value.
However, XML does not allow < and > in attribute values. If you want to get valid XHTML, use a XML serializer:
var s = new XMLSerializer();
var str = s.serializeToString(document.querySelector('a'));
console.log(str);
My Original Link
I'm having some javascript issues with some legacy code, since my company is attempting to upgrade to IE11 from IE8. I have a piece of javascript that finds all commas in a field and replaces it with a couple characters, it is as follows:
document.frm.txt_fieldValue[1].value =
document.frm.txt_fieldValue[1].value.replace(/,/gi, "$0");
In my code this is all on one line, however. This code works in IE8, Chrome, and Firefox. However, in IE9+, specifically IE11 (since this is what my company is upgrading to), this code doesn't replace any commas. I can get it to replace a single comma by using the following code:
document.frm.txt_fieldValue[1].value =
document.frm.txt_fieldValue[1].value.replace(",", "$0");
Because I replaced a single comma, I know my code is reached. But I have searched around and I have yet to find a solid answer. Does anyone else have this problem? If so, has anyone found a solution?
Thanks!
You need to replace it with "$$0", which after escaping will turn into a real $0. I doubt if this code ever worked properly, on any browser.
I recently fixed a bug that might help.
If your value that you were replacing was 0 -- as a value, not a string -- IE11 would only append the replacement string instead of actually replacing it.
Here's what I was working with:
buf = buf.replace( /%%TOTALAMOUNT%%/gim, "$" + parseFloat( g_UserPurchases[LCV].CurrencyValue.val() ).toFixed(2) );
This printed: "%%TOTALAMOUNT%%.00"
I fixed it by checking:
if( ( g_UserPurchases[LCV].CurrencyValue.val() == 0 ) || ( g_UserPurchases[LCV].CurrencyValue.val() === 0 ) ){
//IE fix: IE did not like the $ character and didn't replace if val = 0
buf = buf.replace( /%%TOTALAMOUNT%%/gim, "$0.00"); }
Please note: IE11 didn't replace the the dollar sign character, $. So, I used the character code instead:
$
Hope this helps!
last_tag="abcde x";
last_tag = last_tag.replace(/[\s]+x$/, '');
this is my problem: i have to remove an "x" at the end of my string. This piece of code is used in a plugin i've been using without problems until now. On IE 7 "last_tag" is selected in the wrong way, so i get an "x" and i have to remove it. I think who wrote the plugin added this replace to do exactly this but it's not working on IE7.
Example:
before:last_tag="abcde x"
after: last_tag="abcde"
Actually the problem is that last_tag remain exactly the same.
is the regex correct? is there any error or compatibility issue with IE?
EDIT: Probably the regex is not the issue.
I've tried this piece of code, but nothing happens:
var temp_tag="abc x";
alert(temp_tag);
temp_tag = temp_tag.replace(/[\s]+x$/, '');
alert(temp_tag)
The same piece of code work perfectly on Chrome.
The regex looks okay, but it's possible you're trying to match non-breaking spaces (U+00A0). \s doesn't match those in IE (as explained in this answer), but it does in FireFox and Chrome.
I'd go for this RegExp
/\s+x$/
don't use character class [] for \s which is a character class already
(shorthand for something like [ \t\r\n\v\f]) (space, tab, carriage return, line feed, vertical tab, form feed)
edit
Alan Moore is right:
try this instead
/[\s\u00A0]+x$/
edit
maybe this is case sensitive: maybe \u00a0would not be correct
this should match every white-space-character as well as the non breaking spaces
Try this
last_tag = last_tag.replace(/[\t\r\n]+x$/, '');
I want to make lines of text prefixed with > to be wrapped in <span class="quoted"></span>.
Here is my code:
$(document).ready(function(){
x = $('DIV#test').html();
x = x.replace(/(^|\n)>([^\n]+)(\n|$)/g, "$1<span class=\"quoted\">$2</span>$3");
$('DIV#test').html(x);
});
I can't find a reason why, but this makes only odd lines quoted in Chrome and in IE it makes all text gray. Any ideas what is wrong with this code?
Demo at jsFiddle: http://jsfiddle.net/jBJ6V/1/
Use the m ("multiline") flag on the regular expression rather than the alternation at the outset (and with the necessary adjustments to the resulting capture groups):
$(document).ready(function(){
x = $('DIV#test').html();
x = x.replace(/^>([^\n]+)$/gm, "<span class=\"quoted\">$1</span>");
// Changes: ^----here----^ ^--here ^^--here-^
$('DIV#test').html(x);
});
Updated fiddle
The m flag tells the regular expression to treat ^ and $ as relative to individual lines, not relative to the string as a whole. More in sections 15.10.2.6 and 15.10.2.7 of the specification, and on MDC.
The reason it doesn't work in IE is that older IE handles innerHTML differently, and this reflects in jQuery having different results of .html().
Try this jsfiddle:
http://jsfiddle.net/jBJ6V/8/
I ran it through 7,8 and 9 compatibility modes and seems to be working.