1

When the following page is loaded for the first time (such as when entering the url or opening the file in windows explorer) the iframe is drawn with a border. However, when the page is reloaded/refreshed, there is no border.

<!DOCTYPE html>
<html>
    <head>
    </head>
    <body>
        <iframe 
            src="javascript: window.open('https://www.google.com/images/branding/googlelogo/1x/googlelogo_color_272x92dp.png', '_self')" 
            allowtransparency="true" 
            style="border: none" 
            scrolling="no" 
            frameBorder="0" 
            seamless="seamless">
        </iframe>
    </body>
</html>

I am trying to understand the cause of this and possibly find a workaround for an issue I am facing when integrating with Adobe Captivate, which loads Web Objects using the mechanism below. Any help would be appreciated.

This is from Microsoft Edge Build: 42.17134.1.0

enter image description here

Edit: I know that the rendering of the border is somehow related to the javascript scheme url of the iframe, however that is not something I am able to change. I would like to know the mechanism in Microsoft Edge that causes the border of the iframe to render on the first load. No other browser we support (Chrome/Safari/Firefox) renders the border.

Manual5355
  • 981
  • 10
  • 27
  • 2
    Pretty sure it's that `src` attribute... it should be a plain http/https URL, not a `javascript` scheme URL. – Heretic Monkey Jul 30 '18 at 16:43
  • @HereticMonkey I realize that it the javascript scheme is almost certainly the culprit. Unfortunately, that is not something I am able to change, so I am trying to understand the mechanism in Edge that causes it to render a border around the iframe. No other browser we support renders the border. – Manual5355 Jul 30 '18 at 16:46
  • That's good information that should be in the question... – Heretic Monkey Jul 30 '18 at 16:48
  • Good point. I added an edit to the question. – Manual5355 Jul 30 '18 at 16:51
  • other web browsers use a UserAgent stylesheet for seamless iframes. iframe[seamless] {border:none}… the f12 DOM explorer does not show userAgent style rules. – Rob Parsons Jul 31 '18 at 23:05
  • @RobParsons The example above includes an inline style of "border: none" which should override any user agent style sheet. Additionally, the border does not appear after refreshing the page, which leads me to believe it is not a CSS issue. – Manual5355 Aug 01 '18 at 17:45

2 Answers2

1

If you set the border to something visible like 3px solid red you can clearly tell that no CSS will save you here:

Blockquote

As others have pointed out in the comments this is caused by the javascript:… source attribute. To determine whether there is a full workaround, we'd likely need more information on exactly what part of the <iframe> you are able to change, since you can evidently give it a style attribute. That said, here are some things you can try:

If you can change the src attribute to something completely different

My suggestion would be to have a separate frame.html file with the old src attribute wrapped in a <script> tag, without the javascript: at the beginning:

<script>window.open('https://www.google.com/images/branding/googlelogo/1x/googlelogo_color_272x92dp.png', '_self')</script>

Then, you can change the <iframe> to point to the file. Few things to note:

  • I removed the seamless attribute as it's currently not in the spec and not supported by any browser.
  • The scrolling and frameBorder attributes are obsolete as of HTML5, so I used CSS instead.
  • I found that the T in allowTransparency is meant to be capitalized, but I'm not 100% on that.
<iframe 
    src="frame.html" 
    allowTransparency="true"
    style="border: 0; overflow: hidden">
</iframe>

After these changes the <iframe> appeared as you would expect.

If the value is fixed, but you can add stuff around it

If you cannot move the javascript part, but are able to alter the src attribute otherwise, you may find a data: URL useful instead as an alternative to a separate file. All you need to do is to wrap the attribute's current value in data:text/html;utf8,&lt;script>{ and }&lt;/script>. This creates a valid data: URL pointing to an UTF-8 encoded HTML file that we provide immediately after, which has the same script tag in it. I added brackets to make the javascript: part valid JS syntax by using it as part of an object initialization. This way, the code won't fail due to a syntax error, and window.open is still called.

If you can add JavaScript around the <iframe>

This can also be fixed by some good old JS hackery, using the same method as the first section, but without altering any of the fixed parts or requiring a new file, provided you are able to add JS code outside the <iframe>. Put the following script tag below the <iframe> or place it in a workaround.js file (without the <script> tags) and link it externally. For best results and to make sure any <iframe> elements are parsed by the time the script runs, I suggest placing your <script> tags at the bottom of the <body>.

<script>
    (function(){
        var frames = document.querySelectorAll('iframe[src^="javascript:"]');
        for (var i = 0, l = frames.length; i < l; i++)
            frames[i].src = frames[i].src.replace(/^javascript:(.*)$/, 'data:text/html;utf8,\x3cscript>$1\x3c/script>');
    })();
</script>

This will find all <iframe> tags on the page with a src attribute that starts with javascript: and run the workaround on each of them, fixing the issue.

If none of the above applies

I'm afraid you're out of luck. Short of reporting the issue to Microsoft and getting it fixed you are unlikely to find another solution, to my understanding.

SeinopSys
  • 8,787
  • 10
  • 62
  • 110
  • Thank you for the excellent write up. I've been trying variations of the work arounds you've provided and haven't found something that will work for me yet. I did try reporting the issue to Microsoft, but I have not heard back. To answer my question of why this happens: Would you say this is likely a rendering glitch in Edge, some sort of security behavior, or is the javascript resource identifier considered non standard and unsupported? – Manual5355 Aug 04 '18 at 17:13
  • @JosephShanak I'm quite surprised my final JS approach did not work for you as it should have taken care of the issue provided the ` – SeinopSys Aug 04 '18 at 17:42
  • The last solution had two issues: 1) The iframe is inserted dynamically and I can only specify the src attribute. We used the javascript scheme because we needed to load the url from a variable that exists outside the iframe. However, wrapping it with data:text/html... seems to upset the cross origin policy. 2) Additionally, I don't control when the iframe is loaded so I had to modify the snippet to wait until the iframe was appended to the page. But that issue I solved. – Manual5355 Aug 04 '18 at 18:49
  • I think I found a dirty hack that will solve the issue for now. It involves monkey patching the code that creates the iframe so it can dynamically set the src attribute to an actual URL. I will submit the issue to the EdgeHTML issue tracker again and see what happens. Thank you for the help. – Manual5355 Aug 04 '18 at 18:53
  • In my example I originally left out that the URL was not static for brevity, the src attribute looks closer to this in the real code `src="javascript: window.open(someFunc(), '_self');"` – Manual5355 Aug 04 '18 at 18:56
-1

Can't replicate this problem here. Your screenshot appears to be simply a border, however. Does setting the border using CSS stop this? I.e. border: 0;

<!DOCTYPE html>
<html>
    <head>
    </head>
    <body>
        <iframe style="border: 0px;"
            src="javascript: window.open('https://www.google.com/images/branding/googlelogo/1x/googlelogo_color_272x92dp.png', '_self')" 
            allowtransparency="true" 
            scrolling="no" 
            frameBorder="0" 
            seamless="seamless">
        </iframe>
    </body>
</html>
Nathan Stockton
  • 292
  • 1
  • 5
  • The code example above already has style="border: none". Changing it to style="border: 0;" does not change anything. This issue only manifests in MS Edge as far as I know. – Manual5355 Aug 04 '18 at 16:46