Some stylesheets missing in Edge Inspect when testing Rails app - iphone

I am using Edge Inspect to work with a Rails site on an iPhone.
When I browse to the live site it works fine, but when I browse to the development version some CSS files do not appear to have been loaded. I.E. The page displays without the styles from those CSS files.
However, it does display with the styles from other CSS files defined in exactly the same way! So this does not seem to be about relative vs absolute URLs or ‘localhost’ vs IP address on the network.
Given that the production version (on a real domain) displays fine via Edge Inspect, is it possible that Rails development behaviour is messing up Edge Inspect? In development, Rails creates <link...> tags for every CSS file, whereas in production it concatenates and minifies them.
As an aside: this whole issue is tricky to debug because I don’t see any CSS <link...> tags in the <head> when I inspect the page on the device. That includes the ones which are being applied, so I don’t get where the styles are coming from at all. Is this a foible of how Edge Inspect works? Just on iPhone (5S)?
Anyone seen anything like this?

I solved it!
Turns out my hunch was correct – either Edge Inspect or the iPhone is choking on the large number of individual CSS files.
By changing the relevant stylesheet_link_tag I was able to get it working.
From:
<%= stylesheet_link_tag 'application' %>
To:
<%= stylesheet_link_tag 'application', debug: false %>

Related

TinyMCE Text editor security with HTML

I'm using the free JS plugin from tinymce and interested in preventing an HTML injection with the tinymce text editor.
I've added this property to the INIT:
invalid_elements: 'script' (just for this example)
However nothing happens. The editor still "accepts" the script tag and pass it on.
I looked at https://www.tiny.cloud/docs/tinymce/6/content-filtering/#invalid_elements and it should work but I don't see any change once it's added.
Am I doing something wrong?
Is there a way to limit some HTML elements with this editor?
Any other tips on how to use that editor and prevent the malicious HTML..?
TinyMCE certainly has a variety of configuration options to help you control what content is created in the editor but you can never assume that data provided to you client side is "clean" or "safe". Nefarious people can bypass your front end and all of its validation if their goal is to cause harm to your system.
You should always configure your front end appropriately. TinyMCE has a variety of configuration options to assist with content filtering/validation (https://www.tiny.cloud/docs/configure/content-filtering/) to only allow those types of tags you want created, etc including:
https://www.tiny.cloud/docs/configure/content-filtering/#valid_elements
https://www.tiny.cloud/docs/configure/content-filtering/#extended_valid_elements
https://www.tiny.cloud/docs/configure/content-filtering/#valid_children
https://www.tiny.cloud/docs/configure/content-filtering/#schema
https://www.tiny.cloud/docs/configure/content-filtering/#invalid_elements
However, regardless of the front end design, you should always re-check submitted content on the server to ensure it is safe. There is simply no way around that need. What constitutes "safe" is likely a business decision based on what your application does and who uses it.
There are many different libraries you can use server side to do this sort of validation/cleansing so depending on your specific server side setup you can find libraries that allow you to "sanitize/purify" the submitted HTML.
I would note that TinyMCE (by default) should not allow <script> tags in your content so it is likely that such behavior could be due to your current configuration.

Should HTML email template use table element for the layout?

I have seen bunch of HTML email templates example and all of them use <table> element for layout. Is there any specific reason for using <table>? I tried making one without it and it works for me. Should I be worried that it might break for someone else with different browser?
The main reason tables are still used nowadays is to support Outlook 2007/2010/2013. Those versions use Microsoft Word engine to render HTML, and it's quite a mess. It has a limited support for CSS (no float or position for example), and some CSS properties are only supported on some specific HTML elements. For example, padding is supported on a , but not on a . And even when you could theorically use padding on more semantical elements (like tags), or use margin on elements instead, Word's rendering engine is still massively bugged and can have unpredictable behavior with such HTML and CSS code. Thus, developers find it easier to just use instead.
But here's the thing : if you don't feel like you need to support Outlook 2007/2010/2013, then you can absolutely ditch tables and use better code instead. And even if you need to support it, simple one-column layouts can be done without tables. The reason your template works in Outlook 2011 is that this version (for Mac only) uses WebKit rendering engine (just like in Safari or Apple Mail).
Referring to this old post(why-is-it-still-recommended-to-use-tables-for-email-structure) and some of my own experiments:
We can definitely use HTML tags and not just <table> tag. It gets rendered well in modern browsers. I have personally experimented with Chrome ( which most probably means it works on all chromium based browsers ) and Safari.
Another thing I noticed is, the email clients stripped the template and removed all tags except the main content. In other words, it only rendered what's inside the <body> tag and removed other tags like <html>, <head> including the <body> tag itself. So I don't use those tags in my template at all.

iPhone Stylesheet or JS

I downloaded a template and customised it a bit. It's working well but the template has a kind of mobile style sheet. When I open the webpage with the iPhone, it looks great on the homepage. However, on the most important pages I don't want it to appear for mobile I want it to appear like it would on a browser.
I've tried.
Deleting the: style-mobile.css file. - Nothing happened.
Playing around with the style-mobile.css file. - Nothing!
Deleting some js files.
I can't seem to find the code that is telling my iPhone to open the page like an iPhone instead of opening it like a browser.
Where will I find this??
The idea that you can download an arbitrary HTML/CSS/JS(?) template that is designed for mobiles and have it magically adapt to look right in a classic browser window is .... naive.
Either look for a template that is designed to look good in both contexts, or build your own layouts using something like Twitter Bootstrap which is responsive to differences in the display port size.

Plone rich text tile tries to load incorrect js URL for TinyMCE

Plone 4.2.1.1
plone.tiles 1.2
plone.app.tiles 1.0.1
plone.app.blocks 1.0
plone.app.drafts 1.0a2
Products.TinyMCE 1.2.15
I have a Plone site with two rich text tiles on a page, created following Using tiles to provide more flexible Plone layouts.
The problem is that when editing the tiles, TinyMCE will not load.
In Firebug on the Net tab I see a whole slew of 404s that look like this:
http://example.com/en/front-page/##edit-tile//plugins/pagebreak/editor_plugin.js
By comparison, I know that the correct URLs should look like this:
http://example.com/portal_javascripts/MyTheme/plugins/xhtmlxtras/editor_plugin.js
When I set my portal_javascripts in Development Mode, it works, but when I turn Development Mode off, that's when I see this problem.
So apparently it's due to some kind of javascript conflict, but I don't know where to look for it.
I really need to solve this problem, so any help would be greatly appreciated!
Additional information:
When portal_javascripts has development mode turned off, the condition in this line is never true: https://github.com/plone/Products.TinyMCE/blob/1.2.x/Products/TinyMCE/skins/tinymce/tiny_mce_src.js#L47
That's because the tiny_mce.js file is merged with other files and the name is randomized, and so looking it up by name will always fail. Consequently, the baseURL property of the tinymce object will not be set in init.
Instead, baseURL ends up being set here:
https://github.com/plone/Products.TinyMCE/blob/1.2.x/Products/TinyMCE/skins/tinymce/tiny_mce_src.js#L8397
This is where the URL http://example.com/my-page/##edit-tile/ is used for baseURL.
I verified this by turning off merging and caching in portal_javascripts, but leaving development mode off. Then it works, because it finds tiny_mce.js by name.
Also, I found that when it fails, all of TinyMCE's plugins are added as explicit <script> elements in the head of the iframe (with the ##edit-tile URLs, which can't be loaded). By contrast, when it works, all the plugins are loaded here:
https://github.com/plone/Products.TinyMCE/blob/1.2.x/Products/TinyMCE/skins/tinymce/tiny_mce_src.js#L8458
IOW, they are not added explicitly to the iframe as <script> elements.
(In case I wasn't clear, when I mention iframe, I'm talking about the tile's editing overlay, not TinyMCE's. There is an iframe inside an iframe....)

Use of HTML 5 doctype creates a gap at top of page on iphone safari browser

Update: Please disregard, my problem was caused by an advertisement bar being inserted by the vendor who provides my workplace wireless service.
I was building a mobile friendly website and wanted to use HTML 5. However when I specify the doctype as <!DOCTYPE HTML> , I get a gap at the top of the page on safari on the iphone.
I notice that other sites have the same problem such as nextstop.com and nike.com
I guess safari does not fully support HTML 5 yet. Anybody know of a workaround?
HTML 5 is still in a very unstable state. Don't use it in a production environment.
Edit Just so you guys know what it's about, HTML 5 is currently an Editor's Draft, and the document clearly states (in the Status of This Document section) that this specification is not stable, and that a consensus may not have been reached on any of the proposed sections. I think it should be clear enough that it means it's a bit early to start using it.
All browsers correctly interpret the HTML doctype. Putting it in sets your browser into Standards Compliant mode, that is the only difference with or without the doctype.
You can use a CSS reset tool like http://meyerweb.com/eric/tools/css/reset/ to get rid of default margins and padding on all elements.