When playing a video with the embedded iFrame youtube player, I get a lot of logs in the console. Is there a way to disable this?
I already found an issue posted on the google forum but it isn't solved yet.
Some examples of the logs:
SDK Loader major version = 3
SDK Version = 3.0.48
Loading xlb file for locale - en
Loaded xlb file for locale - en succeed
en_US is not supported. Attempting to trim locale.
Loading xlb file for locale - en
Loaded xlb file for locale - en succeed
It is not a matter of enabling or disabling but a case of extensive logging. It's fixed now:
This inadvertent logging was a bit of an edge case, and it should be fixed later tonight.
(Feb 13, 2013)
See posted issue
Related
Trying to open an attachment with this url and it doesn't work. Any idea why?
https://Blah-apps.com/Development/StrongB.nsf/0/(Attach)/0/B3B9D4480BEF667C852588310078E1AE/$File/golf.pdf!%20&OpenElement
Thanks for any ideas
The attachment was originally created on the web and was an embedded object. I then wrote code to move it to a Rich Text Field and that didn't help. The error I get is
HTTP Web Server: Couldn't find design note
This is from a note that I pulled together for HCL some time ago listing the issues we had with Domino 11 having upgraded from 9. This might help although it is not clear what version you are on.
Broken Download links for LZ1 compressed attachments. - CS0313452
After upgrading to FP5 customers found that they could not download some attachments.
We were able to reproduce this issue 100% and provided HCL with a database.
https://eon.focul.net/eon/apps/moc.nsf/xp_f_mod.xsp?action=openDocument&documentId=67BC79B86B06BAFD802582B30042ACFB FoCul determined that this happens to attachments that are automatically compressed with LZ1 even when the database settings do not enable compression.
+SPR# GRHEBVYNW7 - Server - DAOS - Fixed an issue where after upgrading to 11.x,
running dbmt -c on DAOS enabled databases results in duplicate DAOS objects being stored.
This regression was introduced in 11.0.
The URL syntax affected is the old style https://<>//<>/<database.nsf>>/<>/$FILE/<>.jpg
whereas the newer “XPage”style syntax works fine
We modified our applications to use the XPages style syntax as a good work around.
This is the XPages url style
https://acme.focul.net/apps/moc.nsf/xp_f_mod.xsp?action=openDocument&documentId=67BC79B86B06BAFD802582B30042ACFB
Your use of /0/(Attach)/0 looks wrong. Try this format instead: http://host/Database/View/Document/$File/Filename?OpenElement (source: https://help.hcltechsw.com/dom_designer/9.0.1/appdev/H_ABOUT_URL_COMMANDS_FOR_OPENING_IMAGE_FILES_ATTACHMENTS_AND_OLE_OBJECTS.html)
So in your case:
https://blah-apps.com/Development/StrongB.nsf/0/B3B9D4480BEF667C852588310078E1AE/$File/golf.pdf?OpenElement
I have a Vue.js website with a PDF file which is included in my ultimate javascript bundle via webpack. (It's my CV.) The following build and delivery process has worked perfectly fine for me since 2017, but suddenly stopped working in iOS 14:
Build the PDF with LaTeX.
Use webpack's url-loader to include the PDF in my webpack bundle as a base64 data URI.
Load that URL into a vuex data store, and then just deliver it as a link when clicked.
For the last three years, this has worked fine: I've been able to click on the link and get a working PDF. It's been kind of random and platform-specific whether the PDF opens in-browser or shows up in a download folder, and whether it gets the filename I've asked it to get or not, but, well, that doesn't matter to me. And the core functionality of click the link and get the PDF has worked on every browser and every platform I've ever tried it on.
All of a sudden, with iOS 14, it's stopped working. Now, when I try to activate the PDF link in iOS Safari, nothing happens at all. When I do it in iOS Chrome, it produces a little popup claiming it downloaded a document, but nothing seems to actually be able to open the document. And when I do it in iOS DuckDuckGo, it just displays the base64 data URI in the address bar.
Interestingly, if I take the dataURI that DDG displays in the address bar and copy and paste it into Safari or Chrome on iOS, it actually displays my pdf. So the browsers still have the capacity to display a PDF from a data URI. It just doesn't want to do so from my link.
And my site still works as expected on the desktop. Including in Safari on the desktop. Also, it still works on my wife's phone (she's still on iOS 13). So this is clearly something Apple changed in iOS 14. But what? And how to get my site working again?
I'm guessing that Apple has changed the behavior of the renderer in iOS in some fashion to cause it to break across browsers but nowhere else (since browsers in iOS are all still required to rely on webkit, right?)
This is a pretty important feature to me. I made this decision deliberately for perceived performance---combined with pre-rendering, everything on my site, including the PDF, loads very close to instantly from the user perspective. So I'd really like to keep it.
I'm using Webpack 2.6.1 and Vue 2.3.3. This is a stable build that has been working flawlessly for three years, so I haven't felt the need to update anything except for security updates.
After searching around, I did find this Apple dev discussion which suggests that in iOS 14, Apple newly blocks redirects to data URIs. But I'm not doing a redirect, I'm actually navigating directly to the URI through a link. And the linked discussion suggests that the newly banned behavior just brings Apple in line with what other browsers already ban---but my code works in every other browser, so that can't be it.
Relevant code, to the extent it matters (though it's so basic and obvious that I doubt a simple code fix will be the answer here):
from my webpack.base.js:
{
test: /\.(pdf)$/,
loader: 'url-loader'
},
from my vuex store, in state.js
import cvURL from './assets/pdf/gowdercv.pdf';
from the component containing the link that points to PDF:
<p><a :href="cvURL" download="gowdercv.pdf"><img src="../../assets/icons/file-pdf.svg" class="cvicon"> Download in PDF</a></p>
which is loaded as a computed property to the component, i.e.,
computed: {
cvURL: function(){return this.$store.state.cvURL;},
Does anyone know how to get functionality back in iOS? Is there a workaround built in recent versions of webpack or vue for this? Thanks!
Update: after some help off SO, an acquaintance turned up this similar problem, which also came up with a solution: turning the base64 URI into a blob and passing that data url. Which also solves my problem. Though that SO doesn't have an accepted answer, so I can't vote to close my own question as a duplicate, alas.
I have an embedded youtube video in my nw.js app. The preview for the correct video shows up properly but when I click to play it I am met with the following error:
An error occurred, please try again later
All of the videos in the app get this error, except for one that gets this puzzling error:
The following video contains content from the International Basketball Federation
When I click these videos, I can see the first split second of the video before the error shows up.
I tried enabling/disabling the webkit plugin in the manifest:
"webkit": {
"plugin": true
}
and I tried using the Javascript Player API as suggested by in this post. However I still get the same errors.
How can I get these videos to play properly?
Here is the HTML (I'm using angularJS and the video is in a modal window) that displays the video:
<script type="text/ng-template" id="myModalContent.html">
<object width="100%" height="600px" data={{video}}>
</object>
</script>
I also tried copying this example using the Javascript Player API and even tried using the same video as the example but I'm still getting the same error.
Thank you very much for your time. Let me know if you need anything else from me or if I am being unclear.
Ok so the issue was the ffmpegsumo.dll. At first I tried replacing it with the dll from chrome 39 and 42 and that did not fix my issue. After replacing the file with the ffmpegsumo.dll from Chrome 38.0.2125.122, my issue was fixed and videos played as expected.
Chrome 38.0.2125.122 ffmpegsumo.dll 32 bit
Chrome 38.0.2125.122 ffmpegsumo.dll 64 bit
You need the flash plugins in the plugins directory at the same root level as the package.json NPSWF32_13_0_0_214.dlland NPSWF32_14_0_0_125.dll. This with the above will enable Flash.
Had the same problem in Linux 64 bits using Yeoman Node Webkit Generator (https://github.com/Dica-Developer/generator-node-webkit/wiki/Getting-Started)
Just fixed it by adding the so lib:
$ cp nwjs/nwjs-v0.12.0-linux-x64/libffmpegsumo.so dist/Linux64_v0.12.0/
I am using Howler.js on my PhoneGap application. Because my audio files are large (more than 10Mb) im an setting the buffer attribute to true (forcing HTML5 Audio).
var theSound = new Howl({
urls: ['assets/Sound.m4a'],
buffer: true,
sprite: {
scene0 : [ 1966000, 27000] }
When I test my application on the emulator and my iPad Mobile Safari everything works well. But when I run the application on the iPad as an app, the audio never starts. Using the web inspector I have noted that the audio file tries to load again and again like an not ending loop. You can see an attached screenshot of the resources tab on the web inspector both both the emulator and the iPad, running the same PhoneGap app.
Any idea on what could be the problem?
I've been looking into this for a while.
From what I've gathered, Howler defaults to Web Audio API, and this SO answer says you need a "user input event" to make it work on iOS, because by default it mutes everything. I even tried Howler's own interactive demo on my iPad 2 with iOS 5 (I still haven't updated) here and NONE OF THE SOUNDS WORK. My first link has a link to Apple's documentation, and I haven't tried it yet, but it looks like the convenience of Howler has to be replaced with a lower level implementation that takes about 5-10 lines with XMLHTTPRequest (see the Apple link), or another more versatile library. I'm still learning about what exactly I need, but I have a very similar problem I've been working on resolving today.
But then Howler falls back to HTML5 Audio. OK so I'm just googling that now, and this link comes up, and it's just reminding me of the pletora of compatibility considerations between OGG ACC MP3 etc on various browsers vs. browser layout engines vs. operating systems. So I'm left believing your file format M4A, related to MP3 as far as I can tell, isn't working in the target brower on the target iPad OS. I'm not familiar enough yet to give exact specifics but certainly since Howler doesn't work on my iPad that proves there's at least a problem with that.
The whole point I chose Howler to use was to abstract all the above away! I'm going to go look for another more comprehensive library now =D
the problem might be file size. IPad has a limited cache memory size and if you overflow it assets will not work. The only solution to this problem is smaller file size. Another possibility is html audio will not load or play except in a user event (touch). Web Audio will load but starts muted and only unmutes with a play call inside of a user event.
SoundJS is a library I help develop that handles as much of this stuff as possible. In particular I think you would find the Mobile Safe Approach useful. It is well tested on iOS and Android devices. Unfortunately we do not support sound sprites yet.
Hope that helps.
For my business I need to be able to show a potential client a website I generate with a program called Pano2VR, which is a virtual tour program. This program takes some panoramic photos linked with each other and can generate a virtual tour out of them (as example: www.casas-fotoart.de/virtualtours ). The output this App gives can be either HTML5, Flash or both (flash if available and html5 for mobile devices, for example).
I need to be able to show that on my iPad while offline. i haven't found any solution for that so I tried to build a easy App for that, which I thought it wouldn't be complicated.
I generated a html5-only virtual tour and I droped the output into the "Suporting Files" group on the Xcode project. I added a UIWebView and on viewDidLoad I set it so it loads the html file.
The files I'm droping are like these (these inside the ipad folder):
The html file loads into the webView, but it just displays "This content requires HTML5/CSS3, WebGL, or Adobe Flash Player Version 9 or higher.", even though when loading these files from the net, it loads perfectly. I know this message comes from the html file.
Any idea on how to make it work will be much appreciated. Thanks in advance.
Your problem is this probably - XCode is mangling the JS files, I assume because it's trying to compile them