Bug 857023 - webadmin: BLOCK Chrome browser
Summary: webadmin: BLOCK Chrome browser
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine-webadmin-portal
Version: 3.1.0
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: ---
: ---
Assignee: Einav Cohen
QA Contact: Pavel Stehlik
URL:
Whiteboard: ux
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-09-13 12:11 UTC by Yaniv Kaul
Modified: 2013-07-04 02:51 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-09-17 12:35:42 UTC
oVirt Team: ---
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

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.


Note You need to log in before you can comment on or make changes to this bug.