Submission reject reason is:
1120.3.6.40 High Resolution Icon - Mail Add-Ins
The image file referenced by the HighResolutionIconURL link must be 128 × 128 pixels.
Your icon Height is: 120. Your Icon Width is: 120.
This is my manifest file:
https://www.outlix.no/api/outlix.xml
Validation is a point in time test; the validation tests are carried out against the manifest submitted at that time. Any updates or changes made to the manifest after submission are not reflected in the validation tests. If you change the manifest or a URL in the manifest you must resubmit your offer.
Related
So I downloaded a MathJax package, unpacked it, modified the settings and uploaded the files to an http domain. Everything worked as well as possible for more than a year.
Two days ago, I copied all files (including the database) to a new domain, activated SSL and modified .htaccess to translate all addresses into https. This works perfectly for everything except MathJax "Can't load web font" resulting in a 10 second delay every time it attempts to draw expressions.
Neither Firefox nor Chrome show any kind of errors in the console or failed file reads (cache off, 200 OK). The only effect in the browsers is that there is a 9-10 second gap between /mathjax/jax/output/HTML-CSS/fonts/STIX-Web/Main/Regular/Main.js and /mathjax/jax/output/HTML-CSS/fonts/STIX-Web/Main/Italic/Main.js.
Approximate timeline …
2 s: read (success) /mathjax/jax/output/HTML-CSS/fonts/STIX-Web/Main/Regular/Main.js
11.5 s: read (success) /mathjax/jax/output/HTML-CSS/fonts/STIX-Web/Main/Italic/Main.js
12 s: read (success) /mathjax/fonts/HTML-CSS/STIX-Web/woff/STIXMathJax_Main-Regular.woff
Log (last 4 lines) …
Loading [MathJax]/jax/output/HTML-CSS/fonts/STIX-Web/Main/Regular/Main.js
Loading web-font STIX-Web/Main/Regular
Can't load web font STIX-Web/Main/Regular
Loading [MathJax]/jax/output/HTML-CSS/fonts/STIX-Web/Main/Italic/Main.js
In the timeline, the seconds are the timestamps of the attempts, not the durations. Those are 0-100 ms each.
What I have tried:
Reset .htaccess, loaded everything with http, recopied all MathJax files from old domain to the new one and made sure all directories and files have the proper permissions. I have also entered the paths (in the address bar) to the failing woff files and they download properly. Furthermore, I have disabled SSL and modified the script tags to read the settings file and MathJax from the old domain – still a 10 second delay before attempting to read font files.
How can I tell why MathJax can't load a web font? Why does MathJax, with identical code, add a delay on one site but not the other? Is there a way to troubleshoot this?
Update:
This is now really weird!! After cross-loading files between the sites, I have narrowed down the error to be connected to my CSS file!… which passes validation perfectly (and contains no font changes, between sites, at all). The main change I've done in that file is to add wrapping divs to most elements directly inside body in order to style the wrappers at 100% width, but have the content at 80%.
It turns out that MathJax (2.6.0 and 2.7.2) failed to load a font because I set a min-width on #MathJax_Font_Test. I did not do this on purpose and had no idea it would break. Here's my fix:
body > div > div:not(#MathJax_Font_Test) {
min-width: 960px;
}
I am getting this error when pasting a picture in Xpage rich text editor and save the document; this mainly happens when picture size is big or resolution is good. Please let me know if there is any solution for the same?
Error while executing active content filter Exception in processing active content:
Exception in processing active content:
Illegal state: 62 (>) Exception in processing active content:
Illegal state: 62 (>)
If you use the insert functionallity of CKEditor, the image is uploaded to the server first and then referenced in the CKEditor. But when pasting an image, it is encoded as a base64 string and added directly as a HTML image element:
<img alt="" src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAADIAAAASXCAIAAACs2nJrAAAgAElEQVR4nOzdd3RVdb738fn7mZnnqjOOM6MztrFRLCjFQpFepRelKUhHWigJJQmBhE5IgCSk0EILNR1CEqpYriMlCc2uBPTe50raSSIK3uePvc+uv10UPBuP7"/>
As long as the image is small enough, the Active Content Filter (ACF) is able to parse the content of the CKEditor (HTML code), but as soon the pasted image is too large, the parser crashes.
Please try to disable the content filter by adding the htmlFilter properties set to identify:
<xp:inputRichText
id="inputRichText1"
value="#{document1.Body}"
htmlFilterIn="identify"
htmlFilter="identity">
</xp:inputRichText>
Hope this helps!
EDIT:
This would allow users to embed "malicious" HTML code.
If it's caused by the file size, this may be getting restricted by the "Maximum size of request content" in the HTTP Protocol Limits section on the Internet Protocols > HTTP tab of the server document. You may also need to change the "Maximum POST data (in
kilobytes):" setting in the POST Data section of the Internet Protocols > Domino Web Engine tab.
I configured my .htaccess to lazyload images using mod_pagespeed, but I don't want to affect the user experience by showing an image that is not loaded yet.
Is there a way to set a configuration and lazyload images some pixels before they become visible in the viewport using mod_pagespeed?
If you enable image lazy-loading in mod_pagespeed, the default behavior is to load images on "on scroll". We do have existing code paths to change this to "onload" - aka, load images after onload has fired, but unfortunately we haven't yet exposed it as a configuration flag. A feature for one of the upcoming releases! :-)
Current filter documentation:
https://developers.google.com/speed/docs/mod_pagespeed/filter-lazyload-images
Unfortunately, there is no current way to add an "offset" to when lazyload starts loading the image. It's currently set to the bottom of the viewport, and no option is exposed to configure this. However, I think this would be a valuable option to expose, and I've recorded your feature request at https://code.google.com/p/modpagespeed/issues/detail?id=644.
I have a blog that uses Channel Images to upload and manage images. The content area is a WYGWAM field. I have a few sizes set up in Channel Images to allow the user to adjust the layout inside their content (landscape left, landscape right, portrait left, portrait right) when adding images to the WYGWAM content field. I then have two other sizes: thumb and gallery. These are for the image gallery that appears below the content. Thumb is set as the small preview in the field settings, and gallery is set as the big preview in the field settings. It all works great in the CP publish form.
However, when using the Safecracker form things don't work as well. I can select existing images, but when I add a photo to the content field (WYGWAM) it does not resize it properly. I do get the dialog box and options I want to choose from, but that choice is not being saved.
What happens is the image is added to the WYGWAM content using the size I have selected in the field settings as the big preview. I tested this by changing what size is selected for "big preview".
However, if I upload a new image and select a size it works fine. The issue is only with existing images (ie uploaded previously for other entries).
Is it possible to use sizes in Channel Images/safecracker/wygwam?
It was a bug in the most recent build. The developer has sent me a patched version that is working.
If an image from another site, is loaded to a page, and then written to canvas as a partial ingredient in a composite, using:
context.drawImage(image, 0, 0, w, h);
it would seem anything insecure would already have occurred on the draw to the canvas.
Why then would
window.location = canvas.toDataURL('image/png');
present an error message. SECURITY_ERR; DOM Exception 18. It doesn't seem any more insecure than the extra step of saving the external site image elsewhere first.
My question is not how to get around this, so much, or what the error means, but rather,
Why is this insecure? If the page is loaded by the server the action is surely expected by the author.
As per the spec, information leakage can occur if scripts from one origin can access information (e.g. read pixels) from images on another origin. The worry is that a malicious app could deduce information that it otherwise wouldn't have access to by loading in an image from another domain/origin (easily done with images) and reading the pixel content. XHR has protections built in place to prevent XD leakage. Images do not.