10 Replies Latest reply on Nov 19, 2009 4:35 AM by ilya_shaikovsky

    bug-report:

      In Firefox 3.0.7, when using mode="ajax" in rich:panelMenu,
      a "wyciwyg://(#RandomNumber#)/" prefix is added to the urlbar.

      For example, trying to use panelMenu in http://localhost/testPage.jsf results in navigating to wyciwyg://68/http://localhost/testPage.jsf"

      The issue occurs if the page is already in Firefox cache.

      Today I localized the problem:

      There is a window.setTimeout( function() {..},0);
      in A4J.AJAX.replacePage(req)
      called from A4J.AJAX.processResponse().

      This timer-triggered function opens current html-document for writing:
      window.document.open(req.getContentType(), true);

      At this moment a "wyciwyg://(#number)/" prefix is added to the url-bar!!


      I was unable to simplify this issue in order to submit it on bugzilla.mozilla.org. I hope, richfaces developers can do so.







        • 1. Re: bug-report:
          nbelaevski

          Thank you for reporting, Dmitry! We'll check.

          • 2. Re: bug-report:

            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:

              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:

                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

                  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

                    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

                      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

                        I meant change navigation rules to 'redirect' - forum swaped the '<' tags.

                        • 9. Re: bug-report:
                          mpickell

                          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