[jira] [Updated] (TRINIDAD-2469) trinidad date picker selects previous day when using lightweight dialogs
[ https://issues.apache.org/jira/browse/TRINIDAD-2469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paresh Kumar Acharya updated TRINIDAD-2469: --- Status: Patch Available (was: Open) trinidad date picker selects previous day when using lightweight dialogs - Key: TRINIDAD-2469 URL: https://issues.apache.org/jira/browse/TRINIDAD-2469 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 2.1.1-core Reporter: Paresh Kumar Acharya The issue is with tr:inputDate control, when you select a date between Mar 9 and Nov 2, it keeps selecting the previous day. The issue seems to be specific around day light saving time. If the customer remove the lightweight dialogs change then it opens as a popup and works correctly without any issues. The issue occurs when the server's current date is non DST and clients date is in DST. -- This message was sent by Atlassian JIRA (v6.2#6252)
[Commit Request]TRINIDAD-2469 - trinidad date picker selects previous day when using lightweight dialogs
Hi Committers, Could someone please commit the patch attached to the trinidad issue TRINIDAD-2469 on trunk? Thanks Regards, Paresh
[jira] [Created] (TOBAGO-1389) Disable Hotkey-Behaviour
Matthias Wronka created TOBAGO-1389: --- Summary: Disable Hotkey-Behaviour Key: TOBAGO-1389 URL: https://issues.apache.org/jira/browse/TOBAGO-1389 Project: MyFaces Tobago Issue Type: Improvement Components: Core Reporter: Matthias Wronka Priority: Minor Whenever a label (e.g. of a tx:in) contains a underscore (_), tobago creates a hotkey (alt + character after _) for the corresponding input-field. However, this is not always the desired behaviour e.g. for generic frontends where the labels are not controlled by the developer. I would appreciate a possibility to deactivate this feature globally. Furthermore an explicit way to configure HotKeys (e.g. via an extra-attribute) would be great. This would also enable the application to use the same hotkeys in multi-language-applications (like Ctrl+P is used for Drucken in german applications) -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (TOBAGO-1390) Can't parse to any measure
Bernhard Stadler created TOBAGO-1390:
Summary: Can't parse to any measure
Key: TOBAGO-1390
URL: https://issues.apache.org/jira/browse/TOBAGO-1390
Project: MyFaces Tobago
Issue Type: Bug
Components: Core
Affects Versions: 2.0.0-beta-2
Environment: Firefox 28.0
Reporter: Bernhard Stadler
In our application, there are frequent occurences of IllegalArgumentExceptions
in org.apache.myfaces.tobago.layout.Measure line 79 (function
valueOf(String)), which is being called by
org.apache.myfaces.tobago.renderkit.PageRendererBase line 86 (function
decodePageState(FacesContext, AbstractUIPage)).
I wasn't able to create a reproducing example, but I have been able to isolate
the conditions and causes under which this happens in our application:
Apparently it is caused by JavaScript code (tobago.js, storeClientDimension)
sending decimal values (e.g. 1298.4px) as positions or dimensions.
Measure.valueOf only checks whether the String received ends with px and
removes it if necessary, but doesn't have any means to handle decimals.
In the JavaScript code, I found out that the non-integer value stems from the
following lines in function augmentWidthOrHeight( elem, name, extra,
isBorderBox, styles ) in jquery-1.10.2.js:
{code}
// at this point, extra isn't border nor margin, so remove border
if ( extra !== margin ) {
val -= jQuery.css( elem, border + cssExpand[ i ] + Width, true, styles );
}
{code}
Removing the following lines from our CSS file seems to stop the errors from
occurring:
{code}
.tobago-page {
width: 90%;
height: 99%;
// ...
}
{code}
I'm not sure whether this is a correct use of CSS but I guess it shouldn't
cause a RuntimeException, especially as it is caused by unsanitized client
data.
I don't know what the best course of action might be:
a) Change the JavaScript code to remove decimal places
b) Change Measure to remove decimal places
c) Change Measure to actually store decimals instead of integers
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TOBAGO-1388) Wandering popup
[
https://issues.apache.org/jira/browse/TOBAGO-1388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13979759#comment-13979759
]
Udo Schnurpfeil commented on TOBAGO-1388:
-
It seems to use position() instead of offset() resolves the problem. I've
commited the change to the trunk.
Wandering popup
---
Key: TOBAGO-1388
URL: https://issues.apache.org/jira/browse/TOBAGO-1388
Project: MyFaces Tobago
Issue Type: Bug
Affects Versions: 2.0.0-beta-1
Environment: Custom Theme
Reporter: Bernhard Stadler
Assignee: Udo Schnurpfeil
Attachments: PopupTestModel.java, popuptabletest.xhtml
Original Estimate: 2h
Remaining Estimate: 2h
I have a tc:page containing a tc:popup with a tc:sheet inside. For the sheet,
paging is enabled. I'll attach an example.
Every time the page is changed, the popup changes its position for some
amount.
We have a custom theme and I was able to isolate the following definitions in
our tobago.css file which lay open the problem:
{code}
.tobago-page {
border: 1px solid #EE;
width: 90%;
height: 99%;
// ...
}
{code}
Each of these lines alone causes some amount of popup movement. Removing all
of them makes the problem disappear.
I also was able to isolate the JavaScript code where the actual repositioning
happens:
tobago-theme/tobago-theme-standard/src/main/resources/org/apache/myfaces/tobago/renderkit/html/standard/standard/script/tobago-utils.js
Tobago.Utils.keepElementInVisibleArea line 98f (SVN trunk):
{code}
/**
* fix position, when the element it is outside of the current page
* @param elements is an jQuery Array of elements to be fixed.
*/
Tobago.Utils.keepElementInVisibleArea = function(elements) {
elements.each(function() {
var element = jQuery(this);
var page = jQuery(.tobago-page-content:first);
var left = element.offset().left;
var top = element.offset().top;
// fix menu position, when it is outside of the current page
left = Math.max(0, Math.min(left, page.outerWidth() -
element.outerWidth()));
top = Math.max(0, Math.min(top, page.outerHeight() -
element.outerHeight()));
element.css('left', left);
element.css('top', top);
});
};
{code}
The left and top variables are not changed by the max/min assignment, but
because of (both!) the border and the changed width of the tobago-page class,
element.offset().left and element.offset().top seem to return a different
value than actually needed. Even the following code causes the same behavior:
{code}
Tobago.Utils.keepElementInVisibleArea = function(elements) {
elements.each(function() {
var element = jQuery(this);
element.css('left', element.offset().left);
element.css('top', element.offset().top);
});
};
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TOBAGO-1390) Can't parse to any measure
[
https://issues.apache.org/jira/browse/TOBAGO-1390?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13979796#comment-13979796
]
Udo Schnurpfeil commented on TOBAGO-1390:
-
I think the best way is b)
BTW: Using % values are allowed, but potentially problematic, so I don't use it
;-)
Can't parse to any measure
Key: TOBAGO-1390
URL: https://issues.apache.org/jira/browse/TOBAGO-1390
Project: MyFaces Tobago
Issue Type: Bug
Components: Core
Affects Versions: 2.0.0-beta-2
Environment: Firefox 28.0
Reporter: Bernhard Stadler
In our application, there are frequent occurences of
IllegalArgumentExceptions in org.apache.myfaces.tobago.layout.Measure line
79 (function valueOf(String)), which is being called by
org.apache.myfaces.tobago.renderkit.PageRendererBase line 86 (function
decodePageState(FacesContext, AbstractUIPage)).
I wasn't able to create a reproducing example, but I have been able to
isolate the conditions and causes under which this happens in our application:
Apparently it is caused by JavaScript code (tobago.js, storeClientDimension)
sending decimal values (e.g. 1298.4px) as positions or dimensions.
Measure.valueOf only checks whether the String received ends with px and
removes it if necessary, but doesn't have any means to handle decimals.
In the JavaScript code, I found out that the non-integer value stems from the
following lines in function augmentWidthOrHeight( elem, name, extra,
isBorderBox, styles ) in jquery-1.10.2.js:
{code}
// at this point, extra isn't border nor margin, so remove border
if ( extra !== margin ) {
val -= jQuery.css( elem, border + cssExpand[ i ] + Width, true, styles
);
}
{code}
Removing the following lines from our CSS file seems to stop the errors from
occurring:
{code}
.tobago-page {
width: 90%;
height: 99%;
// ...
}
{code}
I'm not sure whether this is a correct use of CSS but I guess it shouldn't
cause a RuntimeException, especially as it is caused by unsanitized client
data.
I don't know what the best course of action might be:
a) Change the JavaScript code to remove decimal places
b) Change Measure to remove decimal places
c) Change Measure to actually store decimals instead of integers
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Comment Edited] (TOBAGO-1390) Can't parse to any measure
[
https://issues.apache.org/jira/browse/TOBAGO-1390?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13979796#comment-13979796
]
Udo Schnurpfeil edited comment on TOBAGO-1390 at 4/24/14 2:54 PM:
--
I think the best way is a combination of a) and b)
b) to generally prevent for such problems and
a) to round up or down correctly (which can't be decided in b)
BTW: Using % values are allowed, but potentially problematic, so I don't use it
;-)
was (Author: lofwyr):
I think the best way is b)
BTW: Using % values are allowed, but potentially problematic, so I don't use it
;-)
Can't parse to any measure
Key: TOBAGO-1390
URL: https://issues.apache.org/jira/browse/TOBAGO-1390
Project: MyFaces Tobago
Issue Type: Bug
Components: Core
Affects Versions: 2.0.0-beta-2
Environment: Firefox 28.0
Reporter: Bernhard Stadler
Assignee: Udo Schnurpfeil
Fix For: 2.0.0-beta-3
In our application, there are frequent occurences of
IllegalArgumentExceptions in org.apache.myfaces.tobago.layout.Measure line
79 (function valueOf(String)), which is being called by
org.apache.myfaces.tobago.renderkit.PageRendererBase line 86 (function
decodePageState(FacesContext, AbstractUIPage)).
I wasn't able to create a reproducing example, but I have been able to
isolate the conditions and causes under which this happens in our application:
Apparently it is caused by JavaScript code (tobago.js, storeClientDimension)
sending decimal values (e.g. 1298.4px) as positions or dimensions.
Measure.valueOf only checks whether the String received ends with px and
removes it if necessary, but doesn't have any means to handle decimals.
In the JavaScript code, I found out that the non-integer value stems from the
following lines in function augmentWidthOrHeight( elem, name, extra,
isBorderBox, styles ) in jquery-1.10.2.js:
{code}
// at this point, extra isn't border nor margin, so remove border
if ( extra !== margin ) {
val -= jQuery.css( elem, border + cssExpand[ i ] + Width, true, styles
);
}
{code}
Removing the following lines from our CSS file seems to stop the errors from
occurring:
{code}
.tobago-page {
width: 90%;
height: 99%;
// ...
}
{code}
I'm not sure whether this is a correct use of CSS but I guess it shouldn't
cause a RuntimeException, especially as it is caused by unsanitized client
data.
I don't know what the best course of action might be:
a) Change the JavaScript code to remove decimal places
b) Change Measure to remove decimal places
c) Change Measure to actually store decimals instead of integers
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (MYFACES-3888) Resource from classpath locked on windows after change in eclipse
Patrick McLaren created MYFACES-3888:
Summary: Resource from classpath locked on windows after change in
eclipse
Key: MYFACES-3888
URL: https://issues.apache.org/jira/browse/MYFACES-3888
Project: MyFaces Core
Issue Type: Bug
Affects Versions: 2.1.15, 2.1.14, 2.1.13, 2.1.12
Environment: Tomcat in an Eclipse on Windows environment
Reporter: Patrick McLaren
Loading a JSF page from the classpath in Tomcat in an Eclipse on Windows
environment, then changing the JSF file via Eclipse lead to the original file
resource being locked by the finalizer thread trying to close an InputStream to
the file resource. After a GC the resource was overwritable again. The reason
was the unclosed input stream in FaceletCacheImpl.java .
The following patch fixes the issue.
--- java/org/apache/myfaces/view/facelets/impl/FaceletCacheImpl.java8 Jan
2013 14:28:47 - 1.2
+++ java/org/apache/myfaces/view/facelets/impl/FaceletCacheImpl.java24 Apr
2014 16:20:49 -
@@ -154,9 +154,10 @@
{
// Should check for file modification
+URLConnection conn = null;
try
{
-URLConnection conn = facelet.getSource().openConnection();
+conn = facelet.getSource().openConnection();
long lastModified =
ResourceLoaderUtils.getResourceLastModified(conn);
return lastModified == 0 || lastModified target;
@@ -165,6 +166,16 @@
{
throw new FaceletException(Error Checking Last Modified for
+ facelet.getAlias(), e);
}
+// finally close input stream when finished
+finally {
+if (conn != null) {
+try {
+conn.getInputStream().close();
+} catch (IOException e) {
+throw new FaceletException(Error Checking Last
Modified for + facelet.getAlias(), e);
+}
+}
+}
}
return false;
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (MYFACES-3888) Resource from classpath locked on windows after change in eclipse
[
https://issues.apache.org/jira/browse/MYFACES-3888?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick McLaren updated MYFACES-3888:
-
Status: Patch Available (was: Open)
Resource from classpath locked on windows after change in eclipse
-
Key: MYFACES-3888
URL: https://issues.apache.org/jira/browse/MYFACES-3888
Project: MyFaces Core
Issue Type: Bug
Affects Versions: 2.1.12, 2.1.13, 2.1.14, 2.1.15
Environment: Tomcat in an Eclipse on Windows environment
Reporter: Patrick McLaren
Loading a JSF page from the classpath in Tomcat in an Eclipse on Windows
environment, then changing the JSF file via Eclipse lead to the original file
resource being locked by the finalizer thread trying to close an InputStream
to the file resource. After a GC the resource was overwritable again. The
reason was the unclosed input stream in FaceletCacheImpl.java .
The following patch fixes the issue.
--- java/org/apache/myfaces/view/facelets/impl/FaceletCacheImpl.java 8 Jan
2013 14:28:47 - 1.2
+++ java/org/apache/myfaces/view/facelets/impl/FaceletCacheImpl.java 24 Apr
2014 16:20:49 -
@@ -154,9 +154,10 @@
{
// Should check for file modification
+URLConnection conn = null;
try
{
-URLConnection conn = facelet.getSource().openConnection();
+conn = facelet.getSource().openConnection();
long lastModified =
ResourceLoaderUtils.getResourceLastModified(conn);
return lastModified == 0 || lastModified target;
@@ -165,6 +166,16 @@
{
throw new FaceletException(Error Checking Last Modified for
+ facelet.getAlias(), e);
}
+// finally close input stream when finished
+finally {
+if (conn != null) {
+try {
+conn.getInputStream().close();
+} catch (IOException e) {
+throw new FaceletException(Error Checking Last
Modified for + facelet.getAlias(), e);
+}
+}
+}
}
return false;
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TOBAGO-1381) Radio- and Checkbox-Renderer may produce an NullPointerException
[ https://issues.apache.org/jira/browse/TOBAGO-1381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13980199#comment-13980199 ] Hudson commented on TOBAGO-1381: FAILURE: Integrated in tobago-1.0.x #758 (See [https://builds.apache.org/job/tobago-1.0.x/758/]) TOBAGO-1381: Radio- and Checkbox-Renderer may produce an NullPointerException (lofwyr: http://svn.apache.org/viewvc/?view=revrev=1583273) * /myfaces/tobago/branches/tobago-1.0.x/core/src/main/java/org/apache/myfaces/tobago/component/ComponentUtil.java * /myfaces/tobago/branches/tobago-1.0.x/theme/scarborough/src/main/java/org/apache/myfaces/tobago/renderkit/html/scarborough/standard/tag/MenuBarRenderer.java * /myfaces/tobago/branches/tobago-1.0.x/theme/scarborough/src/main/java/org/apache/myfaces/tobago/renderkit/html/scarborough/standard/tag/SelectManyCheckboxRenderer.java * /myfaces/tobago/branches/tobago-1.0.x/theme/scarborough/src/main/java/org/apache/myfaces/tobago/renderkit/html/scarborough/standard/tag/SelectOneRadioRenderer.java * /myfaces/tobago/branches/tobago-1.0.x/theme/scarborough/src/main/java/org/apache/myfaces/tobago/renderkit/html/scarborough/standard/tag/ToolBarRendererBase.java Radio- and Checkbox-Renderer may produce an NullPointerException Key: TOBAGO-1381 URL: https://issues.apache.org/jira/browse/TOBAGO-1381 Project: MyFaces Tobago Issue Type: Bug Components: Themes Affects Versions: 1.0.41, 1.5.13, 2.0.0-beta-2 Reporter: Udo Schnurpfeil Assignee: Udo Schnurpfeil Fix For: 1.0.42, 1.5.14, 2.0.0-beta-3, 2.0.0 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TOBAGO-1382) New attribute name for tc:object
[ https://issues.apache.org/jira/browse/TOBAGO-1382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13980200#comment-13980200 ] Hudson commented on TOBAGO-1382: FAILURE: Integrated in tobago-1.0.x #758 (See [https://builds.apache.org/job/tobago-1.0.x/758/]) TOBAGO-1382: New attribute name for tc:object (lofwyr: http://svn.apache.org/viewvc/?view=revrev=1583339) * /myfaces/tobago/branches/tobago-1.0.x/core/src/main/java/org/apache/myfaces/tobago/taglib/component/ObjectTag.java * /myfaces/tobago/branches/tobago-1.0.x/core/src/main/java/org/apache/myfaces/tobago/taglib/component/ObjectTagDeclaration.java * /myfaces/tobago/branches/tobago-1.0.x/theme/scarborough/src/main/java/org/apache/myfaces/tobago/renderkit/html/scarborough/standard/tag/ObjectRenderer.java New attribute name for tc:object Key: TOBAGO-1382 URL: https://issues.apache.org/jira/browse/TOBAGO-1382 Project: MyFaces Tobago Issue Type: Improvement Components: Core, Themes Affects Versions: 1.0.41, 1.5.13, 2.0.0-beta-2 Reporter: Udo Schnurpfeil Assignee: Udo Schnurpfeil Fix For: 1.0.42, 1.5.14, 2.0.0-beta-3, 2.0.0, 3.0.0 The name attribute of the rendered iframe will use the clientId. The clientId usually contains a colon :, but this doesn't work well in JavaScript window.open(src, target) in Internet Explorer 9 and lower. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TOBAGO-1374) link attribute contains faces mapping
[ https://issues.apache.org/jira/browse/TOBAGO-1374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13980201#comment-13980201 ] Hudson commented on TOBAGO-1374: FAILURE: Integrated in tobago-1.0.x #758 (See [https://builds.apache.org/job/tobago-1.0.x/758/]) TOBAGO-1374: link attribute contains faces mapping (lofwyr: http://svn.apache.org/viewvc/?view=revrev=1578292) * /myfaces/tobago/branches/tobago-1.0.x/core/src/main/java/org/apache/myfaces/tobago/renderkit/html/CommandRendererHelper.java * /myfaces/tobago/branches/tobago-1.0.x/core/src/main/java/org/apache/myfaces/tobago/taglib/decl/HasLink.java * /myfaces/tobago/branches/tobago-1.0.x/core/src/main/java/org/apache/myfaces/tobago/util/StringUtils.java * /myfaces/tobago/branches/tobago-1.0.x/core/src/test/java/org/apache/myfaces/tobago/util/StringUtilsUnitTest.java link attribute contains faces mapping - Key: TOBAGO-1374 URL: https://issues.apache.org/jira/browse/TOBAGO-1374 Project: MyFaces Tobago Issue Type: Bug Affects Versions: 1.0.40, 1.5.12 Reporter: Bernd Bohmann Assignee: Udo Schnurpfeil Fix For: 1.0.41, 1.5.13, 2.0.0-beta-1, 2.0.0 Link contains the faces mapping. The description says only session id and optional context path. Encode action url is called. I think this is wrong. Link to an arbitrary URL, either an internal link or an external link. internal absolute link Starts with a slash '/' character. The context path will be added. A session id will be added, if needed. external link Contains a colon ':' character. The link will not be modified. internal relative link Any other strings. A session id will be added, if needed. Type: java.lang.String -- This message was sent by Atlassian JIRA (v6.2#6252)
