Details

      Description

      Among other things, this bug causes alloy:inputDate and alloy:inputTime to render non-native pickers on mobile devices violating the nativeWhenMobile attribute.

      Steps to reproduce:

      1. Deploy the Alloy Showcase Portlet to Liferay Portal.
      2. Navigate to the alloy:inputDate General exmaple in Chrome.
      3. Right click and select Inspect Element.
      4. Turn on the device toolbar if it isn't already visible (Ctrl or + Shift + M).
      5. Select one of the iPhone options.
      6. Reload the page.
      7. Click the Birthday field.

      If the bug still exists, then an AlloyUI DatePicker will pop up (and the rendered markup will contain <input type="text" />):

      If the bug is fixed, then then a native Chrome date picker will pop up (and the rendered markup will contain <input type="date" />):

        Activity

        Hide
        kyle.stiemann Kyle Stiemann added a comment -

        This issue has a few potential solutions. I think this one is probably the best:

        bridge-impl/**/BrowserSnifferFactoryBridgeImpl could check whether ExternalContext.getRequest() returns an instance of HttpServletRequest or not. If it does, delegate the creation of the BrowserSniffer to the factory chain, if not, return BrowserSnifferPortalImpl. Pro: this requires changes to only one jar, and it seems like the bridge is the most appropriate place to put code that understands that ExternalContext.getRequest() can return different types of requests. Con: this feels like the bridge might know a little bit too much about the implementation of bridge-ext/**/BrowserSnifferFactoryLiferayImpl (which creates an ExternalContextWrapper which returns an HttpServletRequest from getRequest()).

        Alternatively, we could:

        1. Move bridge-impl/**/BrowserSnifferPortalImpl.java to util/**/BrowserSnifferDefaultImpl.java.
        2. Remove all BrowserSniffer code from Bridge Impl.
        3. In Util's BrowserSnifferFactoryImpl, check whether ExternalContext.getRequest() returns an instance of HttpServletRequest or not. If it does, return the non-default BrowserSniffer, if not, return BrowserSnifferDefaultImpl.

        Not sure if there are any pros to this other than it seems better than the solution below. Con: as above this feels like util might need to know a little bit too much about the implementation of bridge-ext/**/BrowserSnifferFactoryLiferayImpl, and this fix would need to be applied in both Util and Bridge Impl.

        Finally, bridge-ext/**/BrowserSnifferFactoryLiferayImpl could unwrap the BrowserSnifferFactory chain until it gets to Util's factory. Pro: this fix only requires changing one jar. Con: this solution requires knowledge of what other facotries on the chain are doing which seems to violate the encapsulation of the BrowserSnifferFactory interface (in other words, we would need to explicitly or implicitly look for Util's factory implementation).

        Show
        kyle.stiemann Kyle Stiemann added a comment - This issue has a few potential solutions. I think this one is probably the best: bridge-impl/**/BrowserSnifferFactoryBridgeImpl could check whether ExternalContext.getRequest() returns an instance of HttpServletRequest or not. If it does, delegate the creation of the BrowserSniffer to the factory chain, if not, return BrowserSnifferPortalImpl . Pro: this requires changes to only one jar, and it seems like the bridge is the most appropriate place to put code that understands that ExternalContext.getRequest() can return different types of requests. Con: this feels like the bridge might know a little bit too much about the implementation of bridge-ext/**/BrowserSnifferFactoryLiferayImpl (which creates an ExternalContextWrapper which returns an HttpServletRequest from getRequest() ). Alternatively, we could: 1. Move bridge-impl/**/BrowserSnifferPortalImpl.java to util/**/BrowserSnifferDefaultImpl.java . 2. Remove all BrowserSniffer code from Bridge Impl. 3. In Util's BrowserSnifferFactoryImpl , check whether ExternalContext.getRequest() returns an instance of HttpServletRequest or not. If it does, return the non-default BrowserSniffer , if not, return BrowserSnifferDefaultImpl . Not sure if there are any pros to this other than it seems better than the solution below. Con: as above this feels like util might need to know a little bit too much about the implementation of bridge-ext/**/BrowserSnifferFactoryLiferayImpl , and this fix would need to be applied in both Util and Bridge Impl. Finally, bridge-ext/**/BrowserSnifferFactoryLiferayImpl could unwrap the BrowserSnifferFactory chain until it gets to Util's factory. Pro: this fix only requires changing one jar. Con: this solution requires knowledge of what other facotries on the chain are doing which seems to violate the encapsulation of the BrowserSnifferFactory interface (in other words, we would need to explicitly or implicitly look for Util's factory implementation).

          People

          • Assignee:
            kyle.stiemann Kyle Stiemann
            Reporter:
            kyle.stiemann Kyle Stiemann
            Participants of an Issue:
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:

              Development

                Subcomponents