Details
-
Type: Bug
-
Status: Closed
-
Priority: Major
-
Resolution: Fixed
-
Affects Version/s: EE-1.8.2.GA_P04, EE-3.0.0.GA_P01, 3.2
-
Fix Version/s: EE-3.3.0.GA, EE-1.8.2.GA_P07
-
Component/s: ICE-Components
-
Labels:None
-
Environment:All
-
Assignee Priority:P3
-
Salesforce Case Reference:
Description
In the "ice:outputStyle" taglib documentation it indicates that the filename contained
in the 'href="file.css"' parameter will also attempt to deliver a browser-specific version of the CSS file
if the browser-specific file is found, and the "file.css" if not.
Icefaces uses the User-Agent header in the request to determine what browser-specific CSS file to deliver.
Browser-specific CSS files look like "file_ie7.css" or "file_ie8.css".
The way this delivery is accomplished in the original code is by appending a new "link" tag to the existing one, so there are then
two links seen in the source, one for the original file and one for the new browser-specific (e.g. "..._ie8.css") one.
In the example application we have two CSS files, and each of their browser-specific counterparts existing in the "css" directory:
css/test1.css
css/test1_ie7.css
css/test1_ie8.css
css/test2.css
css/test2_ie7.css
css/test2_ie8.css
When "ice:outputStyle" tags are provided for both css/test1.css and css/test2.css, we should see four <link> tags like this:
<link href="css/test1.css" rel="stylesheet" type="text/css" />
<link href="css/test1_ie8.css" rel="stylesheet" title="_ie8" type="text/css" />
<link href="css/test2.css" rel="stylesheet" type="text/css" />
<link href="css/test2_ie8.css" rel="stylesheet" title="_ie8" type="text/css" />
Unfortunately, sometimes this doesn't work.
In particular, if an absolute path starting with "/" is used in the "href" attribute, or if a relative path starting with ".."
is used, IceFaces OutputStyleRenderer code looks in the wrong place to determine if the browser-specific version of
the file exists.
-
Hide
- Case11759Example.zip
- 36 kB
- Migration
-
- Case11759Example/build.xml 3 kB
- Case11759Example/.../ant-deploy.xml 3 kB
- Case11759Example/.../build-impl.xml 58 kB
- Case11759Example/.../genfiles.properties 0.5 kB
- Case11759Example/.../private.properties 0.5 kB
- Case11759Example/nbproject/.../private.xml 0.2 kB
- Case11759Example/.../project.properties 3 kB
- Case11759Example/nbproject/project.xml 0.9 kB
- Case11759Example/src/conf/MANIFEST.MF 0.0 kB
- Case11759Example/.../MediceComponentHandler.java 2 kB
- Case11759Example/src/.../MedOutputStyle.java 0.6 kB
- Case11759Example/.../OutputStyleRenderer.java 13 kB
- Case11759Example/web/absolute.xhtml 0.7 kB
- Case11759Example/web/.../absolute.xhtml 0.7 kB
- Case11759Example/web/.../relative.xhtml 0.7 kB
- Case11759Example/web/css/test1.css 0.3 kB
- Case11759Example/web/css/test1_ie7.css 7 kB
- Case11759Example/web/css/test1_ie8.css 0.3 kB
- Case11759Example/web/css/test2.css 0.3 kB
- Case11759Example/web/css/test2_ie7.css 7 kB
- Case11759Example/web/css/test2_ie8.css 0.3 kB
- Case11759Example/web/main.xhtml 2 kB
- Case11759Example/web/.../context.xml 0.1 kB
- Case11759Example/web/readme.txt 4 kB
- Case11759Example/web/relative.xhtml 0.7 kB
- Case11759Example/web/.../medice.taglib.xml 4 kB
- Case11759Example/.../medice-faces-config.xml 0.9 kB
- Case11759Example/web/WEB-INF/web.xml 3 kB
-
-
- Document6.txt
- 5 kB
- yip.ng
-
Hide
- ICE-8758-1.8.2_P07.war
- 5.40 MB
- Cruz Miraback
-
- META-INF/MANIFEST.MF 0.1 kB
- WEB-INF/lib/FastInfoset.jar 285 kB
- WEB-INF/lib/backport-util-concurrent.jar 319 kB
- WEB-INF/lib/commons-beanutils.jar 226 kB
- WEB-INF/lib/commons-collections.jar 558 kB
- WEB-INF/lib/commons-digester.jar 140 kB
- WEB-INF/lib/commons-discovery.jar 75 kB
- WEB-INF/lib/commons-el.jar 110 kB
- WEB-INF/lib/commons-fileupload.jar 56 kB
- WEB-INF/lib/commons-logging.jar 52 kB
- WEB-INF/lib/icefaces-comps.jar 1.77 MB
- WEB-INF/lib/icefaces.jar 1.24 MB
- WEB-INF/lib/jsf-api-1.2.jar 355 kB
- WEB-INF/lib/jsf-impl-1.2.jar 837 kB
- WEB-INF/lib/jstl.jar 20 kB
- absolute.jspx 0.4 kB
- child/absolute.jspx 0.4 kB
- child/relative.jspx 0.4 kB
- css/test1.css 0.3 kB
- css/test1_ie7.css 7 kB
- css/test1_ie8.css 0.3 kB
- css/test2.css 0.3 kB
- css/test2_ie7.css 7 kB
- css/test2_ie8.css 0.3 kB
- main.jspx 1 kB
- readme.txt 4 kB
- relative.jspx 0.4 kB
- WEB-INF/web.xml 2 kB
-
- OutputStyleRenderer.java
- 13 kB
- yip.ng
-
- screenshot-01.png
- 218 kB
-
- screenshot-02.png
- 120 kB
-
- screenshot-03.png
- 88 kB
-
- screenshot-04.png
- 96 kB
-
- screenshot-05.png
- 117 kB
-
- screenshot-06.png
- 126 kB
-
- screenshot-07.png
- 119 kB
-
- screenshot-08.png
- 278 kB
-
- screenshot-09.png
- 137 kB
-
- screenshot-10.png
- 151 kB
Activity
- All
- Comments
- History
- Activity
- Remote Attachments
- Subversion
Done for 3.3: screenshot-05.png, screenshot-06.png, screenshot-07.png. Can't be done for 1.8 because getRealPath() is only available in JSF 2. We never used to check for existence of extra CSS file in 1.8: screenshot-09.png.
User-contributed code is in OutputStyleRenderer.java. Bulk of essential code slightly refactored into method instead of coded inline, so that it is more readable and maintainable. Just minimal refactoring to avoid introducing bugs. By the same token, non-essential code changes were not adopted even though they look cleaner: e.g. screenshot-08.png.
M: C:\svn\ossrepo\icefaces3\trunk\icefaces\compat\components\src\main\java\com\icesoft\faces\component\style\OutputStyleRenderer.java#34165
[12:22:31 PM] Mark Collette: Yip: Ask Deryk about 1.8 ICEfaces utility method that might be equivalent to JSF 2 getRealPath
I believe com.icesoft.faces.util.CoreUtils has a couple of getRealPath methods that use reflection to call getRealPath safely in both portlet and servlet environments.
Deryk
Done for 1.8 as well using CoreUtils.getRealPath(): screenshot-10.png.
M: C:\svn\ossrepo\icefaces\trunk\icefaces\component\src\com\icesoft\faces\component\style\OutputStyleRenderer.java#34220
Confirmed fixed using ICEfaces EE 1.8.2.GA_P07 build2 in IE7/8. Attaching modified war file used for testing.
Comment from the customer on their fix:
To that end, we have created our own "medice:outputStyle" tag, which does provide the correct link tag in all valid circumstances.
This tag is back by code that extends the original icefaces tag code.
In the example application, we have four basic use cases:
Absolute path, top directory
Absolute path, child directory
Relative path, top directory
Relative path, child directory
Each of these uses cases are covered in a separate page. Each one of the pages has one invokation of the "ice:outputStyle" and
one invokation of our version of the "ice:outputStyle" tag - "medice:outputStyle".
All through the examples, the "ice" version of the tag tries to deliver test1.css, and the "medice" version tries to deliver test2.css.
In this back-to-back scenario, we can easily see that all valid paths work for the "medice" version, but some do not work for the
original "ice" version of the tag. For example in the "relative/child" scenario for IE8, we should see:
<link href="../css/test1.css" rel="stylesheet" type="text/css" />
<link href="../css/test1_ie8.css" rel="stylesheet" title="_ie8" type="text/css" />
<link href="../css/test2.css" rel="stylesheet" type="text/css" />
<link href="../css/test2_ie8.css" rel="stylesheet" title="_ie8" type="text/css" />
Instead, viewing the source, we see:
<link href="../css/test1.css" rel="stylesheet" type="text/css" />
<link href="../css/test2.css" rel="stylesheet" type="text/css" />
<link href="../css/test2_ie8.css" rel="stylesheet" title="_ie8" type="text/css" />
The "test1" css that is generated by the "ice" version of the tag, doesn't have the browser-specific link appended. That link tag is missing.
This is incorrect. The "medice" version correctly delivers both in this case.
The only use-case that works correctly is "relative/top".
You want to look at our com.med.icefaces.style.OutputStyleRenderer.encodeEnd(...) method in the sample app.
In it you will find that for the various use-cases, our custom extension of the Icefaces OutputStyleRenderer class searches
for the real browser-specific file on the filesystem in the proper places based on the input "href" path supplied. In some cases,
it will need to detect if the href starts with the context-root, and strip it off, so that the getRealPath can get the real path
of the file, to determine if it really does exist.
(Restricted to icesoft-internal-developers group)