905052 - [v1-train][System] ModalDialog is not displayed occationally when class-0 SMS is received.

Status: RESOLVED DUPLICATE of bug 904470

(Firefox OS Graveyard :: Gaia::System, defect)

Description

[Leo]

Attachment: Repro video

1. Title: ModalDialog is not displayed occationally when class-0 SMS is received.
2. Precondition: This usually happens right after reboot.
3. Tester's Action:  Reboot the device and receive class-0 SMS message.
4. Detailed Symptom (ENG.) : The SMS app is launched but the ModalDialog is not displayed.
5. Expected: A ModalDialog is expected to popup.
6. Reproducibility: Y
1) Frequency Rate : 50%
7. Gaia Master/v1-train: Reproduced on v1-train, (last commit: 913bcdc9d859516133fca5560607e585011dd461)
9. Personal email id: [e-mail]

Comment 1

[Leo]

Attachment: Repro video 2

Comment 2

[Leo]

Leo have created a bug for this at 895795 before, but it was closed because it wasn't reproducible in latest v1-train. 

However when I try now, it is reproduced.. Would you try to repro again?

Thanks

Comment 3

[hanj.kim25]

FYI

I have a feeling that this was related to how 'unpainted' is used in window_manager.js

    if ('unpainted' in openFrame.firstChild.dataset) {
      setFrameBackground(openFrame, transitionOpenCallback);
    } else {
      waitForNextPaint(openFrame, transitionOpenCallback);
    }

Comment 4

[(inactive after 6/18) Alive Kuo [:alive]]

Hmm, maybe, I don't know the root cause. My problem would be I don't have tool to file a class-0 SMS...

About class0 SMS during FTU, it might be another issue because anything shouldn't interrupt FTU, and if that happens, you cannot go back to FTU anymore...

Comment 5

[(inactive after 6/18) Alive Kuo [:alive]]

BTW I don't understand the second video:
Lockscreen -> Unlock -> Homescreen -> the video is ended.
^^^ ??

Comment 6

[hanj.kim25]

(In reply to Alive Kuo [:alive] from comment #5)
> BTW I don't understand the second video:
> Lockscreen -> Unlock -> Homescreen -> the video is ended.
> ^^^ ??

The device receives a class-0 SMS message at 00:22. 
And it is expected a ModalDialog to popup, But it doesn't..

Comment 7

[hanj.kim25]

(In reply to Alive Kuo [:alive] from comment #4)
> Hmm, maybe, I don't know the root cause. My problem would be I don't have
> tool to file a class-0 SMS...
> 
> About class0 SMS during FTU, it might be another issue because anything
> shouldn't interrupt FTU, and if that happens, you cannot go back to FTU
> anymore...

To reproduce the issue, you can fake a regular SMS as a class-0 SMS using the following, in \gaia\apps\sms\js\activity_handler.js

    // Class 0 handler:
    message.messageClass = 'class-0';    <========== fake it
    if (message.messageClass === 'class-0') {


Yes, Receiving class0 SMS during FTU is a different issue. The reason why I tried it during FTU is just because it seems it's easier to reproduce this issue "right after reboot".

Comment 8

[(inactive after 6/18) Alive Kuo [:alive]]

Confirmed:
The root cause is Modal Dialog doesn't get appopen event.
I wonder who modifies window manager recently regress this..on v1-train.

Comment 9

[(inactive after 6/18) Alive Kuo [:alive]]

More investigation:

The appopen event is expected to be fired once the loading of the app is ended if its never launched and painted.
However, the SMS app is launched in background by System Message handler in Window Manager -> Set the iframe bo be unpainted.

But there's a gap between loadend and firstpaint event of the sms is too late so when it's launched by itself, Window Manager is still waiting for the mozbrowserloadend event, but sms is already loaded.

The key point is sms is loaded in background already, but because of its visibility is hidde, the firstpaint event won't occur before it's brought to foreground.

Hi leo, I'd like to know if you will leo+ this one? This affects how I fix this bug.

Comment 10

[(inactive after 6/18) Alive Kuo [:alive]]

See my previous comment.

Comment 11

[(inactive after 6/18) Alive Kuo [:alive]]

Hmm, master is working correctly.....strange.

Comment 12

[(inactive after 6/18) Alive Kuo [:alive]]

It's because master doesn't use firstpaint event but only loadend event to remove the unloaded flag. It doesn't have unpainted flag though.

(In reply to Alive Kuo [:alive] from comment #11)
> Hmm, master is working correctly.....strange.

Comment 13

[Leo]

(In reply to Alive Kuo [:alive] from comment #9)

Nope, we don't have a plan to flag this as leo+ as of now. (No complaint from partner yet.)

We made a simple work-around for now, which is as follows.

1. In window_manager.js, create an getOpeningApp() checking 'opening' in classList.
2. In modal_dialog.js, we have put one more condition to show.

   if (origin == WindowManager.getDisplayedApp() ||
       origin == WindowManager.getOpeningApp() ||        <====== this
       frameType == 'inline-activity')
     this.show(evt.target, origin);
   break;

This was just a work-around..

Comment 14

[(inactive after 6/18) Alive Kuo [:alive]]

(In reply to Leo from comment #13)
> (In reply to Alive Kuo [:alive] from comment #9)
> 
> Nope, we don't have a plan to flag this as leo+ as of now. (No complaint
> from partner yet.)
> 
> We made a simple work-around for now, which is as follows.
> 
> 1. In window_manager.js, create an getOpeningApp() checking 'opening' in
> classList.
> 2. In modal_dialog.js, we have put one more condition to show.
> 
>    if (origin == WindowManager.getDisplayedApp() ||
>        origin == WindowManager.getOpeningApp() ||        <====== this
>        frameType == 'inline-activity')
>      this.show(evt.target, origin);
>    break;
> 
> This was just a work-around..

Hmm, I don't know how to manipulate this bug if this isn't blocking.
I will lower this bug's priority (to me) if nobody thinks patch to only v1-train is necessary.

Comment 15

[Julien Wajsberg [:julienw]]

bug 904470 is exactly the same, and it's leo+.

Alive, I would need your help there. I can reproduce easily using the emulator. Please find more comments there.