Red Hat Bugzilla – Bug 922358
when portal uri is not in trusted sites and user clicks on "install for all users", the page reloads
Last modified: 2015-09-22 09:09 EDT
Description of problem: when portal uri is not in trusted sites and user clicks on "install for all users", the page reloads. The dialog for plugin installation evenually does pop up but the Version-Release number of selected component (if applicable): sf10 RHEV-M: rhevm-spice-client-x86-cab-3.2-2.el6ev.noarch rhevm-userportal-3.2.0-10.14.beta1.el6ev.noarch Windows XP / IE8 client How reproducible: always Steps to Reproduce: 1. on a clean windows XP client, open the User Portal and click Console button of a running VM 2. click the yellow bar, click "install for all users" 3. Actual results: the page reloads after some two minutes, dialog to confirm plugin installation pops up at last Expected results: the page does not reload, dialog pops up immediately Additional info: the bug may be as well in .cab installer
I do not observe 2 minutes delay when downloading CAB file for ActiveX. For local Engine installation + and virtual Windows XP + IE8, the transfer time of ActiveX plugin is not significant. Could be the internet line or browser cache the problem? (cca 17MB must be transfered from the server file /usr/share/spice/SpiceX.cab) - though not probable. It is annoying to click 3x the same button in case the plugin is not installed. But, I think this is influenced by IE browser technology (security + install features) + ActiveX object registration inside HTML. The same is for the additional page reload, we cannot influence it. Warning about security problem is caused by 'iframe' tag use inside HTML page. This is going to be removed soon (see included oVirt patch) - this was introduced because of IE6-7 technology only, now IE>8 should be supported. According to my information, the Spice technology is about to be changed soon. Not sure about automatic installation of Spice plugin using a browser, but the portal application should provide descriptor as an attachment which will be possible to associate with Spice viewer application (currently in master - getAttachment servlet, maybe it will be changed somehow because of a current IE problem when communicating over HTTPS).
(In reply to comment #1) > I do not observe 2 minutes delay when downloading CAB file for ActiveX. For > local Engine installation + and virtual Windows XP + IE8, the transfer time > of ActiveX plugin is not significant. > > Could be the internet line or browser cache the problem? (cca 17MB must be > transfered from the server file /usr/share/spice/SpiceX.cab) - though not > probable. Yes, that might be the case (I was testing over WAN). > > It is annoying to click 3x the same button in case the plugin is not > installed. But, I think this is influenced by IE browser technology > (security + install features) + ActiveX object registration inside HTML. You're right > > The same is for the additional page reload, we cannot influence it. I don't remeber that the reload was necessary in earlier versions... > > Warning about security problem is caused by 'iframe' tag use inside HTML > page. This is going to be removed soon (see included oVirt patch) - this was > introduced because of IE6-7 technology only, now IE>8 should be supported. > Great! <snip>
> Warning about security problem is caused by 'iframe' tag use inside HTML > page. This is going to be removed soon (see included oVirt patch) - this was > introduced because of IE6-7 technology only, now IE>8 should be supported. The oVirt patch cannot be added to this BZ's External Trackers (probably a BZ system bug?) so I'm adding it here: http://gerrit.ovirt.org/#/c/11629/ > Great! I have some bad news, this patch won't solve the issue. The GWT application module gets loaded via <iframe src="javascript:''" ...> However, our beloved IE8 treats <iframe src="javascript:''" ...> as non-secure content, even though SRC attribute doesn't fetch *any* content (iframe is just a dynamic sandbox). The IE8-specific workaround is to use "//:" as SRC attribute. If this doesn't make any sense to you, it's not your fault -- IE8's iframe SRC interpretation is just.. faulty. We are currently deciding on the best way to solve this issue.
Daniel Erez suggested to fix this problem via index.html, which currently just redirects the browser to specific WebAdmin/UserPortal web page. Updated index.html could look like this: <html> <head> <!-- Following two lines taken from GwtHostPage.jsp --> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> <meta http-equiv="X-UA-Compatible" content="IE=edge"> </head> <body> <!-- Load the application via iframe element, SRC value is considered "secure" --> <iframe src="webadmin/WebAdmin.html" style="... fit entire screen ..."></iframe> </body> </html> Assuming users access WebAdmin/UserPortal via index.html, the problem could be solved by using wrapper iframe containing entire GWT application, as shown above. Assuming this issue exist only in IE8, is it really worth the extra effort and added complexity?
(In reply to comment #1) > ... now IE>8 should be supported. correction: at least for the user portal, IE >= 8 should be supported. (In reply to comment #4) > Assuming users access WebAdmin/UserPortal via index.html ... I am not sure that we can assume that; I don't know if / how many users have already bookmarked in their browser the full URL of the user-portal/web-admin page, making this solution unusable for them. In addition, I am not sure how this proposed solution will affect other parts of the application (e.g. ui plugins). > Assuming this issue exist only in IE8, is it really worth the extra effort > and added complexity? not sure. maybe we can settle for release notes on this issue instead (i.e. if you are using IE8, please add the RHEV-M application URL to your trusted sites)? [BTW - mixed content warning on IE8 is also documented in bug 866506 (although it is on the web-admin component, the description is talking about both web-admin and user portal)]
To be clear, all GWT applications using standard iframe-based linker (e.g. WebAdmin & UserPortal) produce "mixed content" warning in IE8. This is because IE8 treats "javascript:''" URL as non-secure content, which is obviously wrong, as the URL doesn't fetch anything from server. In other words, this isn't a problem of the GWT application itself, it's a problem of IE8. More details on this IE8-specific issue can be found here: http://blog.httpwatch.com/2009/09/17/even-more-problems-with-the-ie-8-mixed-content-warning/ This is why I asked "is it really worth the extra effort and added complexity", it's really important to verify if this issue is IE8-specific or persists also in IE9+. If it's IE8-specific, I'd recommend not to fix it, due to extra complexity and given that IE9+ (hopefully) already contain a fix. We shouldn't fix browser bugs in our applications, unless there are really really compelling reasons to do so. > I am not sure that we can assume that; I don't know if / how many users have already bookmarked in their browser the full URL of the user-portal/web-admin page, making this solution unusable for them. I agree, but the workaround on specific {WebAdmin|UserPortal}.html level will be even more complicated. > In addition, I am not sure how this proposed solution will affect other parts of the application (e.g. ui plugins). Assuming UI plugins just use "parent" as reference to immediate parent window, there shouldn't be any issues. > maybe we can settle for release notes on this issue instead (i.e. if you are using IE8, please add the RHEV-M application URL to your trusted sites)? If we confirm this issue is IE8-specific, this is what I'd recommend, don't fix but document it as known issue related to IE8.
Hi, some updates on this issue: * Libor confirmed that this issue is IE8-specific (i.e. doesn't occur in IE9 at all) * Both this bug and bug 866506 seem to have the same root cause, which is IE8's faulty treatment of "javascript:whatever" URLs as non-secure content (despite no request is made at all) * I'd recommend not to fix this issue and instruct users to suppress mixed-content warning dialog and always enable mixed-content in IE8 [1] * The above recommendation is due to: IE9+ doesn't suffer from this issue, WebAdmin officially supports IE9+ only, the fix would introduce considerable complexity just to fix IE8-specific issue [1] see "Suppressing the Mixed Content Warning (for End-users)" section at http://msdn.microsoft.com/en-us/library/ee264315(v=vs.85).aspx
Libor, pls make sure there's a release note,othewise fine with me closing as won'tfix
Please, specify: 1) The release notes concerning the IE8 issue will be attached to this bug? 2) Will UX team provide the official text to IE8 issue? Else the bug cannot be closed soon.
Vojtech: although http://gerrit.ovirt.org/#/c/11629/ didn't fix this issue, I saw that it was merged anyway. So it was merged simply as a clean-up patch (since we don't need that '__gwt_historyFrame' iframe anymore, since we don't need to support IE6-7), and not as a patch that is solving this BZ, correct? (In reply to comment #8) > Libor, pls make sure there's a release note,othewise fine with me closing as > won'tfix Michal(/Libor) - not sure if I understood you correctly; I believe that this bug should be CLOSED WONTFIX *and in addition* contain a release notes (AFAIK - simply flag with "requires_release_note?", choose in the 'Doc Type' field "Release Note" and fill in 'Doc Text' field the release-note content, which should probably be something like: """ IE8 falsely treat "javascript" URLs within HTML tags as non-secure items, resulting in a Mixed Content Warning pop up window, or delay in some flows such as plugin installation (e.g. SPICE ActiveX installation within the user-portal/web-admin). In order to prevent this behavior, you may want to configure your IE8 to suppress mixed content warnings via Internet Options -> Security Settings. [see http://msdn.microsoft.com/en-us/library/ee264315(v=vs.85).aspx for details] """ I would verify all of the above with a PM first (note that no PM has acked this BZ yet).
andy, is it ok to WONTFIX with a release note?
> Vojtech: although http://gerrit.ovirt.org/#/c/11629/ didn't fix this issue, > I saw that it was merged anyway. So it was merged simply as a clean-up patch > (since we don't need that '__gwt_historyFrame' iframe anymore, since we > don't need to support IE6-7), and not as a patch that is solving this BZ, > correct? Correct. The patch you mentioned wasn't intended to fix this issue at all.
Andy - please see Michal's question from Comment #11. Thanks.