Yes, setting that style is the simplest workaround. It just doesn't get
you the blurred affect for the modal overlay, however it accomplishes what
I suspect most people are wanting.
I'm not sure if changes to the framework are necessary either, but as I
said, if any were made, I'd add that visibility call after the blur.play()
on line 964:
// forcing visibility
if (o.owner)
setModalPopupVisible(o.owner, true);
That is the same call that's made if the transition duration style is set
to 0.
I'll document things in chromium's bug database as well as apache's JIRA in
a little bit.
Thanks!
-Jake
On Thu, Feb 13, 2014 at 1:18 PM, Alex Harui <aha...@adobe.com> wrote:
> So can folks set modalTransparencyDuration to 0 as the simplest workaround?
>
> Seems like you should add that info the the Chrome bugs you linked to
> yesterday. Feel free to open a JIRA issue in our bug base. We might just
> close it as external, but at least it will document your findings.
>
> I'm not quite sure I understand what changes we should make to the
> framework, if any.
>
> Thanks,
> -Alex
>
> On 2/13/14 11:09 AM, "Jake Churchill" <reyna...@gmail.com> wrote:
>
> >Alex,
> >
> >I ended up going through the framework code and monkey patching together a
> >solution for this chrome bug. I will leave it to you and more experienced
> >people to determine if it's correct or can be implemented in the framework
> >or if it should be left and eventually fixed by chromium people.
> >
> >In the PopUpManangerImpl.as class non-modal popups just get displayed and
> >their visibility set to true (see showModalWindow method line 826 and
> > showModalWindowInternal method at line 896). At line 834 the
> >modalTransparencyDuration style is pulled (defaulted to 100 by the Sprite
> >class it seems) and this triggers the additional fade/blur transitions at
> >line 908 in showModalWindowInternal. At the end of that logic blog after
> >blur.play() at line 964 the modal window remains invisible. Adding this
> >code:
> >
> >// forcing visibility
> >if (o.owner)
> >setModalPopupVisible(o.owner, true);
> >
> >Fixes that issue for me. This can also be fixed by manually setting that
> >modalTransparencyDuration to 0 in my class that is used for popus:
> >
> >this.setStyle("modalTransparencyDuration",0);
> >
> >The only difference between fixing this in my "monkey patched" class vs.
> >my
> >project class is you still get the blur overlay with the monkey patching,
> >but you don't with setting the style.
> >
> >I'm not sure what else I should do with this information, but please let
> >me
> >know if I should file a bug or something.
> >
> >Thanks!
> >
> >-Jake
> >
> >
> >On Wed, Feb 12, 2014 at 6:51 PM, Alex Harui <aha...@adobe.com> wrote:
> >
> >> It adds 2. But there's lots of interesting stuff going on with the
> >>modal
> >> layer having to do with blur filters and effects and the popup is
> >> invisible for a bit and all that might be confusing PepperFlash. So
> >> breaking it down into individual steps might help show that the
> >>"trigger"
> >> is.
> >>
> >> -Alex
> >>
> >> On 2/12/14 4:19 PM, "Jake Churchill" <reyna...@gmail.com> wrote:
> >>
> >> >In working on this, I found that it was all around the modal layer.
> >>So, I
> >> >just created a global Swiz event to handle adding/removing popup
> >>children
> >> >and I manage the overlay manually by adding a basic component over top
> >>my
> >> >content. The popups are all non-modal, but I'm re-creating the overlay
> >> >manually creating them as modal to the user.
> >> >
> >> >I'll test out the SystemManager direction as well. Curious, when
> >>creating
> >> >a modal popup through PopupManager, does it actually add 2 items to the
> >> >SystemManager (overlay and popup component)? Or is the overlay
> >>something
> >> >built into flash in another way?
> >> >
> >> >Thanks!
> >> >
> >> >-Jake
> >> >
> >> >
> >> >On Wed, Feb 12, 2014 at 5:58 PM, Alex Harui <aha...@adobe.com> wrote:
> >> >
> >> >> As an experiment, don't use PopUpManager and directly add the popup
> >>to
> >> >> SystemManager.popUpChildren.
> >> >>
> >> >> On 2/12/14 2:12 PM, "Jake Churchill" <reyna...@gmail.com> wrote:
> >> >>
> >> >> >Hello again,
> >> >> >
> >> >> >I'm working on an issue where none of my popups display correctly in
> >> >> >chrome. This is via PopUpManager.addPopup(). I know there is a bug
> >> >> >logged
> >> >> >with chromium about this:
> >> >> >
> >> >> >https://code.google.com/p/chromium/issues/detail?id=333024
> >> >> >https://code.google.com/p/chromium/issues/detail?id=323680
> >> >> >
> >> >> >However, I'm wondering if anyone has come across a workaround (no
> >> >>matter
> >> >> >how out of the way it may be). I work on an app where there are
> >>lots
> >> >>of
> >> >> >"wizard" popups and info boxes and in chrome, the majority of the
> >>time
> >> >> >they
> >> >> >just don't display. The modal overlay is there, just not the popup.
> >> >>I've
> >> >> >tried all kinds of combinations of popup parents and childList
> >>settings
> >> >> >and
> >> >> >have modified the popup components that I'm using. I've tried modal
> >> >>and
> >> >> >not, and I've tried forcing invalidatedisplayList() on the parent
> >>and
> >> >> >popup
> >> >> >with no luck.
> >> >> >
> >> >> >I've tried setting wmode="opaque" and wmode="transparent" after
> >>reading
> >> >> >that this might force hardware acceleration off (but it doesn't seem
> >> >>to in
> >> >> >my case).
> >> >> >
> >> >> >The only fixes I've found are to turn hardware acceleration off in
> >> >>chrome
> >> >> >settings or disable the built-in flash player in favor of the
> >>plugin.
> >> >> > Unfortunately, that's not really a viable option to have thousands
> >>of
> >> >> >users do.
> >> >> >
> >> >> >Interestingly enough, when I turn modal off on the popup, it seems
> >>to
> >> >> >sometimes work. I'd really prefer not to "un-modalize" all my
> >>popups
> >> >>for
> >> >> >a
> >> >> >temporary bug in chrome.
> >> >> >
> >> >> >If anyone has any ideas, please let me know.
> >> >> >
> >> >> >Thanks!
> >> >> >
> >> >> >-Jake
> >> >>
> >> >>
> >>
> >>
>
>
