I am looking for a implementation of the "raised mr sign" defined in unicode (version 12.0). I tried to get the character from here:
http://www.fileformat.info/info/unicode/char/1f16c/browsertest.htm
It should be look like this: 🅬 But all I see is a blank rectangle.
It looks like it is not implemented yet by this character-representation: 🅬 in HTML.
I can not find an visual representation of it.
The page says it;
You need a font that supports this character to even have a hope of
seeing it correctly in the browser.
Tested the link on Firefox 69, running on Ubuntu 18 LTS, renders fine.
Related
The documentation seems to state that there are four options for the "display" property within a manifest.json: fullscreen, standalone, minimal-ui and browser
I decided upon 'browser' for one of my apps, but the message from Chrome (Version 76) says "Manifest 'display' property must be one of 'standalone', 'fullscreen' or 'minimal-ui'". The message also appears if I leave 'display' undefined.
Is 'browser' an obsolete option or has it just not made it into the latest Chrome version yet?
(I probably should mention that the message appears in Chrome DevTools>application>manifest).
Valid options for display are fullscreen, standalone, minimal-ui and browser according to https://developer.mozilla.org/en-US/docs/Web/Manifest/display.
In order to show the Add to Home Screen Prompt, display must be set to must be one of: fullscreen, standalone, or minimal-ui, see https://developers.google.com/web/fundamentals/app-install-banners/
browser display option is like leaving the field empty.
When you use standalone it looks like native app. When you use fullscreen there is no status bar etc. Probably you want to use standalone, because fullscreen has very specific use-case (e.g. gaming).
I finally got around to reporting it as a bug.
https://bugs.chromium.org/p/chromium/issues/detail?id=1330323
The immediate response was...
The behaviour is seen from M-85.This is is a non regression issue
hence marking it as untriaged and requesting some one from dev team to
look into the issue.
I have a strange issue regarding a Typo3-Installation (version 6.1). The frontend works fine, but the backend-login is blank (white screen). When I look into the source of the blank page, there is everything there, compared with a working 6.1-instance.
I know, a blank backend comes mostly from some PHP-Errors, but in this case I can't find any. The install-tool says, that everything is fine.
There are no javascript-errors in the blank login and I deleted the typo3-caches. I also tried with different browsers on different machines - still a blank page, but source is there.
Do you have any hints or ideas?
Updating to the latest version (6.2.17) solved that problem.
We are a site located in Belgium. We added the 'locale=nl_BE' parameter to our iframe like button so it says like but in the Dutch language (= "vind ik leuk").
This no longer works. When we change the locale to nl_NL (also Dutch language) the like button works again.
When I check the Facebook Internationalization documentation I can't seem to find Belgium or nl_BE, strange right? This worked for months until yeaserday. http://www.facebook.com/translations/FacebookLocales.xml
jsFiddle: http://jsfiddle.net/Jeroenvdb/cw6js/1/
nl_NL (working): https://www.facebook.com/plugins/like.php?href=http%3A%2F%2Fwww.hln.be%3Futm_source%3Dfacebook%26utm_medium%3Dweb&locale=nl_NL&send=false&layout=box_count&width=0&show_faces=false&action=like&colorscheme=light&font&height=85
nl_BE (not working): https://www.facebook.com/plugins/like.php?href=http%3A%2F%2Fwww.hln.be%3Futm_source%3Dfacebook%26utm_medium%3Dweb&locale=nl_BE&send=false&layout=box_count&width=0&show_faces=false&action=like&colorscheme=light&font&height=85
Facebook just closed the bug report I had posted about the nl_BE issue.
"This locale is not currently supported. But you should be able to load the plugin even if a locale is not supported, it will fallback to en_US locale."
http://developers.facebook.com/bugs/442881812429427
That's just plain silly. The change I see compared to a few months ago is that (as is mentioned in the comment on the bug) share buttons no longer break when you pass an unsupported locale but fallback to en_US.
They should get their language/locale act together.
Must be a new bug or code change at Facebook. Similarly, en_EN which worked before no longer works. en_US does work.
First off, I apologize if it's considered poor etiquette to cross-post on stackexchange sites, but this seemed appropriate for both the webmasters site and here, as it's a common issue for webmaster, but may be able to be solved by coders. In any case, here goes...
OK, so this seems like a really simple problem, but I have yet to find a solution that accomplishes the following:
Opens the link in a new window
Tracks the event in GA when using the asynchronous code
Doesn't trigger pop-up blockers (uses target="_blank" instead of window.open)
Most of the code I've seen, including Google's, doesn't take into account the case of opening in a new window - they just use window location.href.
Even GAAddons (http://gaaddons.com/), which charges for commercial use, seems to not manage opening in new windows properly.
Perhaps, I'm missing something simple - I'd be relieved if so and would thank profusely whoever points it out to me!
If no one is able to provide an example, I'll post some of the test cases I've created to illustrate the problem.
Thanks.
[EDIT] I've since tested the GAAddons code more throughly and have found it to work. I'm guessing the problem that was being reported earlier by a client using Chrome 7 on Windows was more likely a configuration issue than something related to the GAAddons library itself.
You put it in the link's onclick attribute:
some link
The method I've found to satisfy all the requirements I've mentioned is the one found here:
http://cutfromthenorth.com/add-external-link-tracking-with-jquery-and-google-analytics/
It's actually quite simple, leading me to think that there was some other reason why other code wasn't working in earlier tests.
However, I can confirm that the method that's mentioned in the comments on this Google page - http://www.google.com/support/googleanalytics/bin/answer.py?hl=en&answer=55527 - does not meet the above requirements (new windows trigger popup warning on Chrome and IE).
The Google code does work for tracking external links not opened in a new window.
here's the snippet:
$('a[target=_blank]').click(function(){
try{
_gaq.push(['_trackEvent', 'External Links', 'Click', $(this).attr('href')]);
} catch(err) {}
return true;
});
I've tested on the following browsers:
PC:
IE 6 - 9
Firefox 3.6, 4.0
Chrome 9, 10
Safari 5
Opera 11
Mac:
Safari 5
Chrome 10
Firefox 3.6, 4.0
Also tested on iPhone 4 and the native Android browser on Gingerbread
I have 5 users (3 locations) using the pages that have Tiny_MCE text areas.
I receive No Errors and it works Perfectly on the other 4 machines running IE7 This would indicate there is No JavaScript Errors.
One user only is seeing the raw html code and no buttons at all.
I suspect it must be some IE setting that is wrong.
It does not appear that Javascript is disabled, as other Javascript functions work on that same site on the same machine in IE.
This user is running XP Pro, and IE 7.
When I installed FireFox on his machine, the Tiny_MCE works perfectly. This would Also indicate there is No JavaScript Errors.
I'm at a loss to explain it.
Any Ideas would be appreciated.
Thanks
Once I ran into same issue and the fix was to remove a comma at the end of the script. So check whether the error pattern is present in your code.
For example, the following code contains a bug which will prevent it from running in IE7.
tinyMCE.init({
// General options
mode: "textareas",
theme: "advanced",
...
template_replace_values: {
username: "Some User",
staffid: "991234"
}, // <<< BUG - Additional comma here
});
If you can enable javascript debugging in IE7 then post the js error here.
Funny thing. The problem fixed itself with no human assistance. No Reboot, No Nothing. after being AFU for 2 weeks, it just started working again.
Got to Love Windows!
I've encountered this before and it has always been a caching issue. Use Ctrl-F5 in IE to force a full refresh of the page and all its files (*.css, *.js) in the browser and the browser cache. My guess is the IE 7 computer that was bad had a 14 day setting for checking if files were up to date.
Sometimes it's been worse - the web server (tomcat 5.5) would cache the file too and not notice the file was updated. Restarting the web server fixed that.
We are experiencing the same problem with our software last few months.
I found this forum topic on developer's website:
http://tinymce.moxiecode.com/punbb/viewtopic.php?pid=66594
In short words, he is recommending to set strict_loading_mode to true when initializing tinymce. I've done that, and since that i had no problems.