Details
-
Type: Bug
-
Status: Open
-
Priority: Major
-
Resolution: Unresolved
-
Affects Version/s: EE-1.8.2.GA_P04, EE-1.8.2.GA_P05, EE-1.8.2.GA_P06
-
Fix Version/s: None
-
Component/s: Framework
-
Labels:None
-
Environment:IE, Webkit
-
Salesforce Case Reference:
-
Workaround Exists:Yes
-
Workaround Description:Use a non-ICEfaces login page.
Description
With Firefox, instead of relying on the submit type, it simply looks for an input field marked as a password and uses this as its indication to show the dialog.
-
Hide
- Case11803Example.war
- 7.25 MB
- Arran Mccullough
-
- META-INF/MANIFEST.MF 0.1 kB
- META-INF/context.xml 0.1 kB
- WEB-INF/classes/com/.../example/Item.class 0.3 kB
- WEB-INF/classes/.../example/TestBean.class 0.9 kB
- WEB-INF/faces-config.xml 1 kB
- WEB-INF/lib/FastInfoset.jar 281 kB
- WEB-INF/lib/backport-util-concurrent.jar 316 kB
- WEB-INF/lib/commons-beanutils.jar 113 kB
- WEB-INF/lib/commons-collections.jar 162 kB
- WEB-INF/lib/commons-digester.jar 104 kB
- WEB-INF/lib/commons-fileupload.jar 56 kB
- WEB-INF/lib/commons-logging.jar 30 kB
- WEB-INF/lib/icefaces-comps.jar 1.75 MB
- WEB-INF/lib/icefaces-facelets.jar 592 kB
- WEB-INF/lib/icefaces.jar 1.22 MB
- WEB-INF/lib/jsf-api.jar 312 kB
- WEB-INF/lib/jsf-impl.jar 1.14 MB
- WEB-INF/lib/jstl.jar 20 kB
- WEB-INF/lib/jxl.jar 689 kB
- WEB-INF/.../krysalis-jCharts-1.0.0-alpha-1.jar 148 kB
- WEB-INF/lib/standard.jar 380 kB
- WEB-INF/web.xml 4 kB
- main.xhtml 0.8 kB
- welcomeICEfaces.xhtml 2 kB
-
- Case11803Example.zip
- 20 kB
- Arran Mccullough
Activity
- All
- Comments
- History
- Activity
- Remote Attachments
- Subversion
The simplest workaround is to use an HTML or JSP page for just the login page. Was this covered in previous discussions with the customer?
Yes it was. I've documented this as a workaround.
Do we know why they rejected a non-ICEfaces login page?
No, no response was received after providing my analysis of the issue and the available workarounds.
It is likely possible to add a feature to support this in ICEfaces 1.8 (similar to prependId="false", perhaps just for ice:inputText, and to disable the ajax submit on the commandButton) but it is necessary to evaluate this against switching to ICEfaces 3.2 or using an HTML/JSP login.
Arran, was the client saying that simply adding autocomplete='on' to the form tag would solve the problem? Seems to fix the issue for me.
autocomplete="on" didn't seem to work for me in Chrome, but maybe it's version-dependent?
On further testing I see that autocomplete="on" on the form is required, but our captured submit on the form in 1.8 prevents Chrome from prompting to save passwords. In 1.8 we also override the h:form renderer, but the h:form doesn't support the HTML5 autocomplete attribute, only the ice:form.
Attached test case that shows issue.