Icons are displayed properly in the browser but when I try to replay the session via Session replay the icons are missing and icon-name is displayed.
Material icons are imported via CDN.
#import url("https://fonts.googleapis.com/css?family=Material+Icons|Material+Icons+Outlined|Material+Icons+Two+Tone|Material+Icons+Round|Material+Icons+Sharp");
I'm using v-icons like:
<v-icon>keyboard_arrow_down</v-icon>
Datadog Rum init
datadogRum.init({
applicationId: 'xxx',
clientToken: 'xxx',
site: 'us3.datadoghq.com',
service:'xxx',
env:process.env.NODE_ENV,
sampleRate: 100,
trackInteractions: true,
defaultPrivacyLevel: 'allow'
});
datadogRum.startSessionReplayRecording();
What I expect to see in session replays:
What is actually rendered in session replays:
Per the docs, web components are not supported in replay:
Session Replay does not support the following HTML elements at the moment: iframe, video, audio, canvas, as well as Web Components.
Related
I am trying to change the start_url of my PWA app from one page to another but need to understand the working. Can anyone please tell me what will happen to users of my PWA app user (with old start_url). Is there any some kind of update happen after which old user can get the updated start_url.
For example:
PWA with old start_url: www.testweb.com/oldurl
PWA with new start_url: www.testweb.com/newurl
will users of PWA with old URL will get any URL after I change the start_url.
With Chrome, it depends on whether you're on desktop or mobile. On desktop, changing the start_url will have no effect, but on Android, it should be updated within a day or two. See How Chrome handles updates to the web app manifest for details about how manifest changes affect an installed PWA.
My recommendation would be don't change the start_url but instead, use the service worker to redirect the browser to the new page. For example, you could use something like:
self.addEventListener('fetch', (event) => {
// Check if URL is old start_url, if so redirect to new URL
if (event.request.url.endsWith('/previous/start_url.html')) {
const resp = Response.redirect('/new/start_url.html', 301);
event.respondWith(resp);
}
});
My site has several subsections. When a user adds the site to their homescreen, I'd like to make sure that the home screen icon launches them into the subsection they were on when they added to homescreen.
I can register a different manifest for each subsection, but this doesn't work for single page apps where there's no page reload. I'm considering storing the subsection in a cookie and then redirecting from a generic start URL based on that cookie.
Is there a better way to do this?
If you remove the start_url from the manifest.json file then it will default to the page user was browsing while adding pwa app to homescreen.
ref : https://developers.google.com/web/tools/lighthouse/audits/manifest-contains-start_url
Have you tried changing the web app manifest url when the user navigates between different subsections?
document.querySelector('link[rel=manifest]').href = '/example-manifest.json';
One solution is for each page do you have a separated manifest with attribute start_url specific to each page.
Editing:
in the HTML for /your_path:
<link rel="manifest" href="/path/to/your_path-manifest.json">
in the HTML for other pages:
<link rel="manifest" href="/path/to/any_other_page-manifest.json">
Had the same problem just now. Here is my solution:
I completely removed the manifest tag from the initial HTML. Instead I now put the manifest together entirely in JS with the start_url set to window.location.href. Then I add it to the head as a Base64 data URL:
const manifest = {
name: 'My App',
short_name: 'My App',
display: 'standalone',
theme_color: '#ffffff',
background_color: '#ffffff',
icons: [
{ src: `${window.location.origin}/path/to/icon.png`, sizes: '192x192', type: 'image/png' },
{ src: `${window.location.origin}/path/to/icon.png`, sizes: '512x512', type: 'image/png' },
{ src: `${window.location.origin}/path/to/icon.png`, sizes: '192x192', type: 'image/png', purpose: 'maskable' },
{ src: `${window.location.origin}/path/to/icon.png`, sizes: '512x512', type: 'image/png', purpose: 'maskable' }
],
start_url: window.location.href
};
const link = document.createElement('link');
link.rel = 'manifest';
link.href = `data:application/json;base64,${btoa(JSON.stringify(manifest))}`;
document.head.appendChild(link);
Seems to work on both Android and iOS.
Note: Since data URLs don't have a root you cannot specify any root-relative URLs within the manifest (e.g. for icons). But it's easy to fix by prepending with window.location.origin. Also the start_url may not be relative. E.g. using just window.location.pathname doesn't work, that's why I am using window.location.href.
Note 2: If you are using a tool to autogenerate the PWA support of your app make sure this tool doesn't generate its own manifest during the build. Usually there should be a config option to disable this. For the Vite PWA Plugin I was able to configure manifest: false.
Had the same problem and tried messing about with the start_url applying many suggestions and none worked. What did work is to remove start_url all together.
Now I'm able to go to any page under and subdirectory and save the page to my phone home screen, when clicking on the save link I taken to the correct page.
Tested this in Chrome, Safari, Firefox and Edge.
Hope that helps.
I am using Worklight 6.0 and in this case testing with iOS7.
I'm trying to setup saml 2.0 SSO with Worklight and I seem to have succeeded, but I don't know how it works... At first, I have my app attempt to access my url like this:
WLJQ.ajax({
url: 'url.com',
type: 'GET',
xhrFields: {
withCredentials: true
},
success: function(data, status, xhr) {
console.log(data);
},
error: function(result) {
console.log("error");
console.log(result);
}
});
The request goes to success and returns me the url of the login page, which is correct because I haven't authenticated yet, but it does not display the login (as I intended).
Next I click a button to display a Native page (iOS) which is a UIWebView of url.com. This displays the login page via:
WL.NativePage.show('LoginController', backFromNativeLoginPage, params);
I log in successfully and see the contents of url.com that I expect. Then I return back to the non-native app via:
[NativePage showWebView:0];
Now that I'm back in the non-native code, I sent the same request above and I expect for it not to return the contents of url.com, but rather the login page because I have no headers attached to my request and I think the non-native code shouldn't have any knowledge of the cookies I may have made in the UIWebView.
My question is how does this work? Does my non-native part of worklight have knowledge of all the cookies that were created in the native code's UIWebView?
Let me start by saying my answer is partly based on speculation, but I think this is whats happening:
Since your Native page is using the a WebView and Cordova is also using the WebView, any headers and cookies that your Native page is using will be visible when you return from native since cookies are shared across differet UIWebViews.
If your native page was using the native URL request methods or some third party / open source mechanism for connecting to your backend server, then I would think that your non-native page would not be able to see the headers and cookies.
Some days ago my blog's FB comment box plugin started showing a yellow coloured box beneath the comment writing form, showing the message:
Warning: this comments plugin is operating in compatibility mode, but
has no posts yet. Consider specifying an explicit 'href' as suggested
in the comments plugin documentation to take advantage of all plugin
features.
I changed the value from URL to HREF but this way all URL formatted comments are hidden and not visible anymore, although they still remain in memory and they're visible again just changing again the code.
Is there a way to change the code to fit the new requirements, but keeping all the old comments visible?
I wrote a complete tutorial with a small use of JS to solve this issue.
Visit the tutorial.
What I did was:
Set off the parse for XFBML tags in the JS SDK
Adding a function-call to the JS SDK with a date parameter that you manually set it once with a date that posts published after that date will start using the 'href' version, and posts published until that date will use the migrated version.
Adding another attribute to the fb:comments tag which is 'data-date' and in it's value you place your post date (dynamic code).
Calculating the dates in a JS code, and base on the result it's removing the not wanted attributes, and finally then it's render the XFBML tags using FB.XFBML.parse
I just fixed this issue in one site, but my requirement was different. I wanted to load comment box for each image in a gallery. When we click on an image it will start a slide show, and each image's comment will show on side panel like facebook and g+ did.
Here is the code I gone through: http://codekiku.blogspot.in/2012/03/facebook-comment-box-href-versions.html#!http://codekiku.blogspot.com/2012/03/facebook-comment-box-href-versions.html
var fbUrl="http://" + "www.facebook.com/plugins/comments.php?href=" +encodeURIComponent(URL);
fbTag = $('<iframe scrolling="no" frameborder="0" style="border:none;overflow:hidden; width:300px; height:400px" height="400px" width="300px" allowTransparency="true"></iframe>');
$(fbTag).attr('src',fbUrl);
$("#newfb").html(fbTag); // a div which will load the comment box
if(FB==null){
window.fbAsyncInit = function (){
FB.init({
appId: 'xxxxxxxx',// your app id
status: true, // check login status
cookie: true, /*
enable cookies to allow the server
to access the session*/
xfbml: false // parse XFBML
});
}
}
else{
FB.init({
appId: 'xxxxxxx',
status: true, // check login status
cookie: true, /*
enable cookies to allow the server
to access the session*/
xfbml: false // parse XFBML
});
}
While creating a mobile web app with the Facebook javascript SDK, I have one iphone (4, ios5) that is receiving a QUOTA_EXCEEDED_ERR during FB.init. My FB.init looks like:
var channel = '//'+(window.location.hostname+((~[80,443].indexOf(window.location.port))?'':(':'+window.location.port))+'/channel.html');
var APP_ID = 'MYAPPIDXXX';
alert('before FB.init');
FB.init({
appId: APP_ID,
channelUrl: channel,
status: true,
cookie: true,
xfbml: true,
oauth: true
});
alert('after FB.init');
This error seems to be related to localStorage, however after clearing cache on the phone the error still occurs.
I can reproduce (only on that one phone) with an html page that only has the fb-root element and the '//connect.facebook.net/en_US/all.js' script followed by the script above. I am using the html5 doctype and including the facebook namespace in the html tag. It never reaches the second alert. My channel file exists and is being served correctly.
Any ideas as to why this is happening?
Thanks
Found the answer here:
http://frederictorres.blogspot.com/2011/11/quotaexceedederr-with-safari-mobile.html
Turns out that iphone in question had "Private Browsing" enabled in the Safari settings. You can detect private browsing by trying to set an empty string to local storage and checking for a QUOTA_EXCEEDED_ERR as shown here:
http://m.cg/post/13095478393/detect-private-browsing-mode-in-mobile-safari-on-ios5