Bug 857023

Summary: webadmin: BLOCK Chrome browser
Product: Red Hat Enterprise Virtualization Manager Reporter: Yaniv Kaul <ykaul>
Component: ovirt-engine-webadmin-portalAssignee: Einav Cohen <ecohen>
Status: CLOSED WONTFIX QA Contact: Pavel Stehlik <pstehlik>
Severity: high Docs Contact:
Priority: unspecified    
Version: 3.1.0CC: acathrow, dyasny, ecohen, iheim, jkt, Rhev-m-bugs, ykaul
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard: ux
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-09-17 12:35:42 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Yaniv Kaul 2012-09-13 12:11:30 UTC
Description of problem:
The fact we have small warning in the login page is not enough.
The fact is, there are some severe issues when working with it. For example, you cannot set a static IP to a NIC - it's not enabled!

This already led to several false positive bug reports from QE, and surely will cause Support issues.

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:

Comment 1 Dan Yasny 2012-09-13 12:22:43 UTC
I don't think we should block it, just enhance the message about the browser not supporting the GWT tech well enough. Completely blocking something off doesn't look good, IMO

Comment 2 Yaniv Kaul 2012-09-13 12:36:33 UTC
(In reply to comment #1)
> I don't think we should block it, just enhance the message about the browser
> not supporting the GWT tech well enough. Completely blocking something off
> doesn't look good, IMO

I didn't think so either - but I've been convinced that it'll cause issues.

Comment 3 Itamar Heim 2012-09-13 14:24:52 UTC
but it is useful for just browsing/looking around, so also not sure we should block it.

Comment 4 Yaniv Kaul 2012-09-13 14:27:16 UTC
(In reply to comment #3)
> but it is useful for just browsing/looking around, so also not sure we
> should block it.

Unless you forget it's just for browsing/looking around, as happens often in QE - and we file bugs that don't reproduce on others' - till we figure out it's Chrome. That's my main concern. It's not that it looks bad or something - behavior is inconsistent. I'm not even talking about the difference I see in behavior *between chrome versions*.

Comment 5 Pavel Stehlik 2012-09-14 10:30:34 UTC
in this case, I've one RFE as well:

blocking IE8 (non-compliance with standards, terrible slow{as result of using JS}, drag & drop doesn't work).

the similar with IE9 except slowness

The customer can have an impression that our product looks/behaves unusable.

Comment 6 Yaniv Kaul 2012-09-14 18:14:26 UTC
(In reply to comment #5)
> in this case, I've one RFE as well:
> 
> blocking IE8 (non-compliance with standards, terrible slow{as result of
> using JS}, drag & drop doesn't work).

I disagree. There's a big difference between working slow and working wrong.

> 
> the similar with IE9 except slowness
> 
> The customer can have an impression that our product looks/behaves unusable.

I am surprised, however, that this probably still the most popular IE version - http://en.wikipedia.org/wiki/Internet_Explorer#Desktop_Market_share_by_year_and_version (although stats are not up-to-date).

One reason may be because it's the latest (and last) IE supported on XP.

Comment 7 Andrew Cathrow 2012-09-17 12:22:21 UTC
I don't agree with blocking Chrome - we need to find the bugs and fix them, if we can't log into the portal then this won't happen.

Comment 8 RHEL Program Management 2012-09-17 12:35:42 UTC
Product Management has reviewed and declined this request.
You may appeal this decision by reopening this request.