-
1. Re: bug-report:
nbelaevski Mar 13, 2009 7:19 PM (in response to alexeev.net)Thank you for reporting, Dmitry! We'll check.
-
2. Re: bug-report:
mvitenkov Mar 16, 2009 8:54 AM (in response to alexeev.net)I can't reproduce issue, you described.
My environment:
JSF 1.2_10 + facelets; RF 3.3.1-SNAPSHOT; TOMCAT 6.0.16; FF 3.0.7
My code:<h:form> <rich:panelMenu mode="ajax"> <rich:panelMenuItem> <h:outputText value="panelMenuItem" /> </rich:panelMenuItem> </rich:panelMenu> </h:form>
I tried it with org.richfaces.LoadScriptStrategy="DEFAULT" and "ALL". -
3. Re: bug-report:
alexeev.net Mar 17, 2009 9:18 AM (in response to alexeev.net)Hi, Mihey,
the rich:panelMenuItem in your code does not contain any action
no action => no ajax request
no ajax request => no A4J.AJAX.processResponse
no A4J.AJAX.processResponse => no A4J.AJAX.replacePage(req)
no A4J.AJAX.replacePage(req) => no window.document.open(...)
no window.document.open => no wyciwyg-Bug
please read my first post, I made a huge debug session, before I localized the issue..."mvitenkov" wrote:
I can't reproduce issue, you described.
My environment:
JSF 1.2_10 + facelets; RF 3.3.1-SNAPSHOT; TOMCAT 6.0.16; FF 3.0.7
My code:<h:form> <rich:panelMenu mode="ajax"> <rich:panelMenuItem> <h:outputText value="panelMenuItem" /> </rich:panelMenuItem> </rich:panelMenu> </h:form>
I tried it with org.richfaces.LoadScriptStrategy="DEFAULT" and "ALL". -
4. Re: bug-report:
mvitenkov Mar 18, 2009 9:41 AM (in response to alexeev.net)Hi, Dmitry,
rich:panelMenuItem contain action now:<rich:panelMenu mode="ajax" id="panelMenuID"> <rich:panelMenuItem action="#{custom.action}"> <h:outputText value="Go to main page" /> </rich:panelMenuItem> </rich:panelMenu>
But issue, you described still not reproducible for me. Am I doing something wrong? Could you please attach your project(war,ear) for better reproduction and describe your environment.
Thanks for participation! -
5. Re: bug-report:
bitec Mar 21, 2009 6:04 PM (in response to alexeev.net)Actually I have the same problems with the new version of Firefox. Customers were in panic after firefox automatic update, when each second click directed the request to "wyciwyg://". I couldn't find the reason and simply rollbacked firefox on each of computer, but this seems very strange...
-
6. Re: bug-report:
mpickell Nov 17, 2009 9:03 AM (in response to alexeev.net)Has there been a solution for this? I am seeing it right now and have a ticket open with Firefox as a bug. I linked them to this post.
-
7. Re: bug-report:
bitec Nov 17, 2009 4:31 PM (in response to alexeev.net)The reason of this is using a4j:commandLink as navigation links. You can do 2 things: change navigation links to h:commandLink or change the navigation rules to in faces-config.xml
-
8. Re: bug-report:
bitec Nov 17, 2009 4:33 PM (in response to alexeev.net)I meant change navigation rules to 'redirect' - forum swaped the '<' tags.
-
9. Re: bug-report:
mpickell Nov 18, 2009 7:57 PM (in response to alexeev.net)Thanks for the advice Bitec!
In our case, that wasn't what was happening, but it did help to put us in the right direction.
For some reason, we had our navigation-case (inside the navigation-rule) in the faces-config.xml file set up with a "from-outcome" and "to-view-id" but without a "from-action". not sure how we missed it.
This combination caused the "wyciwyg://#/" to prefix the URL on the third or fourth click into the application. for us anyway, and it was very repeatable.
I am not intimately familiar with the navigation rules, if someone could offer an explanation of this, it would be good to put in my bug-report on the firefox site so they are aware as well. -
10. Re: bug-report:
ilya_shaikovsky Nov 19, 2009 4:35 AM (in response to alexeev.net)consider this also http://www.jboss.org/community/wiki/CommonAjaxRequestsProblems#navigation