[JBoss JIRA] (RF-13645) contextMenu for extendedDataTable breaks after ajax render of contextMenu
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-13645?page=com.atlassian.jira.plugin.s... ]
Brian Leathem edited comment on RF-13645 at 5/27/14 6:00 PM:
-------------------------------------------------------------
QE: Please verify this potential regression.
was (Author: bleathem):
Please verify this potential regression.
> contextMenu for extendedDataTable breaks after ajax render of contextMenu
> -------------------------------------------------------------------------
>
> Key: RF-13645
> URL: https://issues.jboss.org/browse/RF-13645
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-menu
> Affects Versions: 4.3.5, 4.3.6
> Environment: WIN7 / JBOSS AS 7.1.1
> Reporter: Steffen Michel
> Assignee: Pavol Pitonak
> Priority: Blocker
>
> Anything that causes an ajax re-render of a contextMenu which is attached to an extendedDataTable causes the contextMenu to subsequently be broken, triggering a JavaScript error instead of displaying the menu. The error seems to be this:
> {quote}
> Cannot call method 'show' of null in menu-base.js (at line 108 there is a call to this.popup, but popup is null)
> {quote}
> The reason I need to ajax re-render the context menu is because in my situtation it's held within a tab panel, and if it doesn't get re-rendered then it stops working after switching tabs using ajax mode (though it also breaks if the contextMenu is held outside of the tab panel, so that isn't a potential solution).
>
> I created a stripped down example of my specific situation, with two extended data tables, each held in a different tab within a tab panel, and one context menu for each table. Changing tabs will cause the context menu to break without it explicitly being called in a render list. The same kind of break occurs if the contextMenu is called as part of any ajax render list:
> {code}
> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
> "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
> <html xmlns="http://www.w3.org/1999/xhtml" xmlns:h="http://java.sun.com/jsf/html" xmlns:rich="http://richfaces.org/rich">
> <h:head></h:head>
> <h:body>
> <h:form id="testForm">
> <rich:tabPanel>
> <rich:tab id="tab1" header="Tab 1">
> <rich:extendedDataTable value="#{testBean.items}" var="beanVar" id="table1">
> <rich:column id="col1"> <h:outputText value="#{beanVar}"/>
> </rich:column>
> </rich:extendedDataTable>
> <rich:contextMenu id="contextMenu1" target="table1">
> <rich:menuItem render="table1,contextMenu1" mode="ajax"
> actionListener="#{testBean.addItem}">Context Menu 1 Item</rich:menuItem>
> </rich:contextMenu>
> </rich:tab>
> <rich:tab id="tab2" header="Tab 2">
> <rich:extendedDataTable value="#{testBean.items}" var="beanVar2" id="table2">
> <rich:column id="col2">
> <h:outputText value="#{beanVar2}"/>
> </rich:column>
> </rich:extendedDataTable>
> <rich:contextMenu id="contextMenu2" target="table2">
> <rich:menuItem render="table2,contextMenu2" mode="ajax"
> actionListener="#{testBean.addItem}">Context Menu 2 Item</rich:menuItem>
> </rich:contextMenu>
> </rich:tab>
> </rich:tabPanel>
> </h:form>
> </h:body>
> </html>
> {code}
> And a simple test bean:
> {code}
> import org.apache.myfaces.extensions.cdi.core.api.scope.conversation.ViewAccessScoped;
> import javax.inject.Named;
> import java.io.Serializable;
> import java.util.ArrayList;import java.util.List;
> @Named
> @ViewAccessScoped
> public class TestBean implements Serializable {
> List<String> items = new ArrayList<>();
> public TestBean() {
> items.add("one");
> items.add("two");
> items.add("three");
> }
> public void addItem(){
> items.add("another");
> }
> public List<String> getItems() {
> return items;
> }
> }
> {code}
> The above test situation works fine in richfaces 4.3.1, 4.3.2, 4.3.3 and 4.3.4, but breaks when upgraded to 4.3.5.Final.
>
>
> There was a different bug fixed in 4.3.5 which seems highly related to this, but opposite, making me wonder if whatever was done there caused this bug instead (but it's just a guess): RF-11973
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
9 years, 11 months
[JBoss JIRA] (RF-13647) File Download throws exception
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-13647?page=com.atlassian.jira.plugin.s... ]
Brian Leathem updated RF-13647:
-------------------------------
Steps to Reproduce:
Here's my code from xhtml
{code}
<h:commandLink action="#{campaignBean.campaignDownload()}" value="#{ifn:translate('Excel File')}"/>
{code}
Backing bean code
{code}
public void campaignDownload() throws Exception {
File f= new File(logDir + fileName);
/* This is an Omnifaces Utility which will simply gives the file to browser. I tried that but it didn't work either
The same code works fine in 4.3.5 Final and 4.3.4 Final.
http://stackoverflow.com/questions/9391838/how-to-stream-a-file-download-...
*/
//Faces.sendFile(f,true);
try {
FacesContext context = FacesContext.getCurrentInstance();
/* Code that reads content from file and store it in object */
IBinaryContentProvider binaryContentProvider = dfAction.getBinaryContentProvider();
HttpServletResponse response = (HttpServletResponse) context.getExternalContext().getResponse();
response.setContentType(binaryContentProvider.getContentMIMEType());
response.setHeader("Content-Disposition", "attachment; filename="
+ binaryContentProvider.getDownloadFilename());
ServletOutputStream ouputStream = response.getOutputStream();
while (binaryContentProvider.hasMoreChunks()) {
byte[] bytes = binaryContentProvider.getNextChunk();
// it is ok to have 0 bytes
if (bytes != null && bytes.length > 0) {
ouputStream.write(bytes);
}
}
} catch (Exception ex) {
logger.error(Level.SEVERE, "Exception : " + ex);
} finally {
FacesContext.getCurrentInstance().responseComplete();
}
}
{code}
was:
Here's my code from xhtml
<h:commandLink action="#{campaignBean.campaignDownload()}" value="#{ifn:translate('Excel File')}"/>
Backing bean code
public void campaignDownload() throws Exception {
File f= new File(logDir + fileName);
/* This is an Omnifaces Utility which will simply gives the file to browser. I tried that but it didn't work either
The same code works fine in 4.3.5 Final and 4.3.4 Final.
http://stackoverflow.com/questions/9391838/how-to-stream-a-file-download-...
*/
//Faces.sendFile(f,true);
try {
FacesContext context = FacesContext.getCurrentInstance();
/* Code that reads content from file and store it in object */
IBinaryContentProvider binaryContentProvider = dfAction.getBinaryContentProvider();
HttpServletResponse response = (HttpServletResponse) context.getExternalContext().getResponse();
response.setContentType(binaryContentProvider.getContentMIMEType());
response.setHeader("Content-Disposition", "attachment; filename="
+ binaryContentProvider.getDownloadFilename());
ServletOutputStream ouputStream = response.getOutputStream();
while (binaryContentProvider.hasMoreChunks()) {
byte[] bytes = binaryContentProvider.getNextChunk();
// it is ok to have 0 bytes
if (bytes != null && bytes.length > 0) {
ouputStream.write(bytes);
}
}
} catch (Exception ex) {
logger.error(Level.SEVERE, "Exception : " + ex);
} finally {
FacesContext.getCurrentInstance().responseComplete();
}
}
> File Download throws exception
> ------------------------------
>
> Key: RF-13647
> URL: https://issues.jboss.org/browse/RF-13647
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: core
> Affects Versions: 4.3.6
> Environment: Richfaces 4.3.6 Final.
> Mojarra - 2.1.28
> Weblogic 12.1.2
> Windows 7
> Reporter: santhosh siravuri
> Priority: Critical
>
> File download action throws below exception.
> ]] Root cause of ServletException.
> java.lang.NullPointerException
> at org.richfaces.renderkit.AjaxCommandRendererBase.isSubmitted(AjaxCommandRendererBase.java:83)
> at org.richfaces.renderkit.AjaxCommandRendererBase.doDecode(AjaxCommandRendererBase.java:59)
> at org.richfaces.renderkit.RendererBase.decode(RendererBase.java:80)
> at javax.faces.component.UIComponentBase.decode(UIComponentBase.java:789)
> at javax.faces.component.UIComponentBase.processDecodes(UIComponentBase.java:1183)
> Truncated. see log file for complete stacktrace
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
9 years, 11 months
[JBoss JIRA] (RF-13647) File Download throws exception
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-13647?page=com.atlassian.jira.plugin.s... ]
Brian Leathem updated RF-13647:
-------------------------------
Description:
File download action throws below exception.
{code}
]] Root cause of ServletException.
java.lang.NullPointerException
at org.richfaces.renderkit.AjaxCommandRendererBase.isSubmitted(AjaxCommandRendererBase.java:83)
at org.richfaces.renderkit.AjaxCommandRendererBase.doDecode(AjaxCommandRendererBase.java:59)
at org.richfaces.renderkit.RendererBase.decode(RendererBase.java:80)
at javax.faces.component.UIComponentBase.decode(UIComponentBase.java:789)
at javax.faces.component.UIComponentBase.processDecodes(UIComponentBase.java:1183)
Truncated. see log file for complete stacktrace
{code}
was:
File download action throws below exception.
]] Root cause of ServletException.
java.lang.NullPointerException
at org.richfaces.renderkit.AjaxCommandRendererBase.isSubmitted(AjaxCommandRendererBase.java:83)
at org.richfaces.renderkit.AjaxCommandRendererBase.doDecode(AjaxCommandRendererBase.java:59)
at org.richfaces.renderkit.RendererBase.decode(RendererBase.java:80)
at javax.faces.component.UIComponentBase.decode(UIComponentBase.java:789)
at javax.faces.component.UIComponentBase.processDecodes(UIComponentBase.java:1183)
Truncated. see log file for complete stacktrace
> File Download throws exception
> ------------------------------
>
> Key: RF-13647
> URL: https://issues.jboss.org/browse/RF-13647
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: core
> Affects Versions: 4.3.6
> Environment: Richfaces 4.3.6 Final.
> Mojarra - 2.1.28
> Weblogic 12.1.2
> Windows 7
> Reporter: santhosh siravuri
> Priority: Critical
>
> File download action throws below exception.
> {code}
> ]] Root cause of ServletException.
> java.lang.NullPointerException
> at org.richfaces.renderkit.AjaxCommandRendererBase.isSubmitted(AjaxCommandRendererBase.java:83)
> at org.richfaces.renderkit.AjaxCommandRendererBase.doDecode(AjaxCommandRendererBase.java:59)
> at org.richfaces.renderkit.RendererBase.decode(RendererBase.java:80)
> at javax.faces.component.UIComponentBase.decode(UIComponentBase.java:789)
> at javax.faces.component.UIComponentBase.processDecodes(UIComponentBase.java:1183)
> Truncated. see log file for complete stacktrace
> {code}
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
9 years, 11 months
[JBoss JIRA] (RF-13645) contextMenu for extendedDataTable breaks after ajax render of contextMenu
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-13645?page=com.atlassian.jira.plugin.s... ]
Brian Leathem updated RF-13645:
-------------------------------
Description:
Anything that causes an ajax re-render of a contextMenu which is attached to an extendedDataTable causes the contextMenu to subsequently be broken, triggering a JavaScript error instead of displaying the menu. The error seems to be this:
{quote}
Cannot call method 'show' of null in menu-base.js (at line 108 there is a call to this.popup, but popup is null)
{quote}
The reason I need to ajax re-render the context menu is because in my situtation it's held within a tab panel, and if it doesn't get re-rendered then it stops working after switching tabs using ajax mode (though it also breaks if the contextMenu is held outside of the tab panel, so that isn't a potential solution).
I created a stripped down example of my specific situation, with two extended data tables, each held in a different tab within a tab panel, and one context menu for each table. Changing tabs will cause the context menu to break without it explicitly being called in a render list. The same kind of break occurs if the contextMenu is called as part of any ajax render list:
{code}
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xmlns:h="http://java.sun.com/jsf/html" xmlns:rich="http://richfaces.org/rich">
<h:head></h:head>
<h:body>
<h:form id="testForm">
<rich:tabPanel>
<rich:tab id="tab1" header="Tab 1">
<rich:extendedDataTable value="#{testBean.items}" var="beanVar" id="table1">
<rich:column id="col1"> <h:outputText value="#{beanVar}"/>
</rich:column>
</rich:extendedDataTable>
<rich:contextMenu id="contextMenu1" target="table1">
<rich:menuItem render="table1,contextMenu1" mode="ajax"
actionListener="#{testBean.addItem}">Context Menu 1 Item</rich:menuItem>
</rich:contextMenu>
</rich:tab>
<rich:tab id="tab2" header="Tab 2">
<rich:extendedDataTable value="#{testBean.items}" var="beanVar2" id="table2">
<rich:column id="col2">
<h:outputText value="#{beanVar2}"/>
</rich:column>
</rich:extendedDataTable>
<rich:contextMenu id="contextMenu2" target="table2">
<rich:menuItem render="table2,contextMenu2" mode="ajax"
actionListener="#{testBean.addItem}">Context Menu 2 Item</rich:menuItem>
</rich:contextMenu>
</rich:tab>
</rich:tabPanel>
</h:form>
</h:body>
</html>
{code}
And a simple test bean:
{code}
import org.apache.myfaces.extensions.cdi.core.api.scope.conversation.ViewAccessScoped;
import javax.inject.Named;
import java.io.Serializable;
import java.util.ArrayList;import java.util.List;
@Named
@ViewAccessScoped
public class TestBean implements Serializable {
List<String> items = new ArrayList<>();
public TestBean() {
items.add("one");
items.add("two");
items.add("three");
}
public void addItem(){
items.add("another");
}
public List<String> getItems() {
return items;
}
}
{code}
The above test situation works fine in richfaces 4.3.1, 4.3.2, 4.3.3 and 4.3.4, but breaks when upgraded to 4.3.5.Final.
There was a different bug fixed in 4.3.5 which seems highly related to this, but opposite, making me wonder if whatever was done there caused this bug instead (but it's just a guess): RF-11973
was:
Look here:
https://community.jboss.org/message/873478?et=watches.email.thread#873478
> contextMenu for extendedDataTable breaks after ajax render of contextMenu
> -------------------------------------------------------------------------
>
> Key: RF-13645
> URL: https://issues.jboss.org/browse/RF-13645
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-menu
> Affects Versions: 4.3.5, 4.3.6
> Environment: WIN7 / JBOSS AS 7.1.1
> Reporter: Steffen Michel
> Priority: Blocker
>
> Anything that causes an ajax re-render of a contextMenu which is attached to an extendedDataTable causes the contextMenu to subsequently be broken, triggering a JavaScript error instead of displaying the menu. The error seems to be this:
> {quote}
> Cannot call method 'show' of null in menu-base.js (at line 108 there is a call to this.popup, but popup is null)
> {quote}
> The reason I need to ajax re-render the context menu is because in my situtation it's held within a tab panel, and if it doesn't get re-rendered then it stops working after switching tabs using ajax mode (though it also breaks if the contextMenu is held outside of the tab panel, so that isn't a potential solution).
>
> I created a stripped down example of my specific situation, with two extended data tables, each held in a different tab within a tab panel, and one context menu for each table. Changing tabs will cause the context menu to break without it explicitly being called in a render list. The same kind of break occurs if the contextMenu is called as part of any ajax render list:
> {code}
> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
> "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
> <html xmlns="http://www.w3.org/1999/xhtml" xmlns:h="http://java.sun.com/jsf/html" xmlns:rich="http://richfaces.org/rich">
> <h:head></h:head>
> <h:body>
> <h:form id="testForm">
> <rich:tabPanel>
> <rich:tab id="tab1" header="Tab 1">
> <rich:extendedDataTable value="#{testBean.items}" var="beanVar" id="table1">
> <rich:column id="col1"> <h:outputText value="#{beanVar}"/>
> </rich:column>
> </rich:extendedDataTable>
> <rich:contextMenu id="contextMenu1" target="table1">
> <rich:menuItem render="table1,contextMenu1" mode="ajax"
> actionListener="#{testBean.addItem}">Context Menu 1 Item</rich:menuItem>
> </rich:contextMenu>
> </rich:tab>
> <rich:tab id="tab2" header="Tab 2">
> <rich:extendedDataTable value="#{testBean.items}" var="beanVar2" id="table2">
> <rich:column id="col2">
> <h:outputText value="#{beanVar2}"/>
> </rich:column>
> </rich:extendedDataTable>
> <rich:contextMenu id="contextMenu2" target="table2">
> <rich:menuItem render="table2,contextMenu2" mode="ajax"
> actionListener="#{testBean.addItem}">Context Menu 2 Item</rich:menuItem>
> </rich:contextMenu>
> </rich:tab>
> </rich:tabPanel>
> </h:form>
> </h:body>
> </html>
> {code}
> And a simple test bean:
> {code}
> import org.apache.myfaces.extensions.cdi.core.api.scope.conversation.ViewAccessScoped;
> import javax.inject.Named;
> import java.io.Serializable;
> import java.util.ArrayList;import java.util.List;
> @Named
> @ViewAccessScoped
> public class TestBean implements Serializable {
> List<String> items = new ArrayList<>();
> public TestBean() {
> items.add("one");
> items.add("two");
> items.add("three");
> }
> public void addItem(){
> items.add("another");
> }
> public List<String> getItems() {
> return items;
> }
> }
> {code}
> The above test situation works fine in richfaces 4.3.1, 4.3.2, 4.3.3 and 4.3.4, but breaks when upgraded to 4.3.5.Final.
>
>
> There was a different bug fixed in 4.3.5 which seems highly related to this, but opposite, making me wonder if whatever was done there caused this bug instead (but it's just a guess): RF-11973
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
9 years, 11 months
[JBoss JIRA] (RF-13640) autocomplete cant select by mouse
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-13640?page=com.atlassian.jira.plugin.s... ]
Brian Leathem commented on RF-13640:
------------------------------------
Thanks for clarifying [~ppitonak], I am able to reproduce this following your instructions.
> autocomplete cant select by mouse
> ---------------------------------
>
> Key: RF-13640
> URL: https://issues.jboss.org/browse/RF-13640
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-input
> Affects Versions: 4.3.6
> Environment: Firefox 29.0.1
> Chrome 35.0.1916.114
> Reporter: liumin hu
> Assignee: Brian Leathem
> Labels: regression
> Fix For: 4.3.8
>
>
> the suggestion list of autocomplete can not be selected by mouse, always the first one selected.
> there is not this bug before 4.3.6.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
9 years, 11 months
[JBoss JIRA] (RF-13640) autocomplete cant select by mouse
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-13640?page=com.atlassian.jira.plugin.s... ]
Brian Leathem updated RF-13640:
-------------------------------
Labels: regression (was: )
> autocomplete cant select by mouse
> ---------------------------------
>
> Key: RF-13640
> URL: https://issues.jboss.org/browse/RF-13640
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-input
> Affects Versions: 4.3.6
> Environment: Firefox 29.0.1
> Chrome 35.0.1916.114
> Reporter: liumin hu
> Assignee: Brian Leathem
> Labels: regression
> Fix For: 4.3.8
>
>
> the suggestion list of autocomplete can not be selected by mouse, always the first one selected.
> there is not this bug before 4.3.6.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
9 years, 11 months
[JBoss JIRA] (RF-13642) Fork and re-factor the asciidoc-based docs from RF 5 to RF 4.5
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-13642?page=com.atlassian.jira.plugin.s... ]
Brian Leathem updated RF-13642:
-------------------------------
Labels: needs-qe (was: )
> Fork and re-factor the asciidoc-based docs from RF 5 to RF 4.5
> --------------------------------------------------------------
>
> Key: RF-13642
> URL: https://issues.jboss.org/browse/RF-13642
> Project: RichFaces
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: doc
> Reporter: Brian Leathem
> Assignee: Brian Leathem
> Labels: needs-qe
> Fix For: 4.5.0.Alpha3
>
> Original Estimate: 1 day, 4 hours
> Remaining Estimate: 1 day, 4 hours
>
> Steps involved:
> # Fork the master branch of the docs repo (we'll call the new branch {{4.5.x}}
> # Revert any changes addressing:
> #* RF 5 component replacements
> #* RF 5 package renames
> #* Facelet namespace consolidation
>
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
9 years, 11 months
[JBoss JIRA] (RF-13642) Fork and re-factor the asciidoc-based docs from RF 5 to RF 4.5
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-13642?page=com.atlassian.jira.plugin.s... ]
Brian Leathem updated RF-13642:
-------------------------------
Description:
Steps involved:
# Fork the master branch of the docs repo (we'll call the new branch {{4.5.x}})
# Revert any changes addressing:
#* RF 5 component replacements
#* RF 5 package renames
#* Facelet namespace consolidation
was:
Steps involved:
# Fork the master branch of the docs repo (we'll call the new branch {{4.5.x}}
# Revert any changes addressing:
#* RF 5 component replacements
#* RF 5 package renames
#* Facelet namespace consolidation
> Fork and re-factor the asciidoc-based docs from RF 5 to RF 4.5
> --------------------------------------------------------------
>
> Key: RF-13642
> URL: https://issues.jboss.org/browse/RF-13642
> Project: RichFaces
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: doc
> Reporter: Brian Leathem
> Assignee: Brian Leathem
> Labels: needs-qe
> Fix For: 4.5.0.Alpha3
>
> Original Estimate: 1 day, 4 hours
> Remaining Estimate: 1 day, 4 hours
>
> Steps involved:
> # Fork the master branch of the docs repo (we'll call the new branch {{4.5.x}})
> # Revert any changes addressing:
> #* RF 5 component replacements
> #* RF 5 package renames
> #* Facelet namespace consolidation
>
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
9 years, 11 months