Firefox OS v1.3 Mozilla build ID:20140422024003 +++ This bug was initially created as a clone of Bug #738206 +++ DEFECT DESCRIPTION: The message interface display erro when click "back" options quickly REPRODUCING PROCEDURES: PRE:have some message in the DUT. 1.Enter into message 2.click a conversations quickly,click "back"option,quickly 3.repeat setp 2 some times 4.the message niterface display erro--K.O EXPECTED BEHAVIOUR: K.O--message interface should display correct ASSOCIATE SPECIFICATION: TEST PLAN REFERENCE: TOOLS AND PLATFORMS USED: USER IMPACT:medium REPRODUCING RATE:1/6 For FT PR, Please list reference mobile's behavior: ++++++++++ end of initial bug #738206 description ++++++++++
Can you please check on a more recent version? I think we fixed this. The issue is probably that we call scrollIntoView on the last SMS when we're not in the thread panel.
Dear Julien, I don't know which build did you fixed this bug, because we just have build:20140422024003. Thus can you give the patch to me? Thanks a lot.
(In reply to Julien Wajsberg [:julienw] from comment #6) > Can you please check on a more recent version? I think we fixed this. > > The issue is probably that we call scrollIntoView on the last SMS when we're > not in the thread panel. No, I don't think you are right, because this bug can still be reproduced even if it dosen't scroll at all in a very short sms.
qawanted to check if latest master has this bug
(In reply to 田旻 from comment #8) > (In reply to Julien Wajsberg [:julienw] from comment #6) > > Can you please check on a more recent version? I think we fixed this. > > > > The issue is probably that we call scrollIntoView on the last SMS when we're > > not in the thread panel. > > No, I don't think you are right, because this bug can still be reproduced > even if it dosen't scroll at all in a very short sms. I'll check this but I think we call this function all the time even when the thread is not scrollable. The result is that if the element is not displayed (because we aleady left the panel) we get the behavior you see.
I think this has been fixed by the navigation refactoring in bug 881469 and its follow-up bug 1022755. If you want to fix it in v1.3 or v1.4, this is IMO the easiest: * in ThreadUI.scrollViewToBottom: check that the hash starts with "#thread="
Unable to reproduce this bug on Flame 2.1 with the variables below. Actual Results: No error or broken UI is seen when going in and out of a message thread many times quickly. Repro Rate: 0/30 Environmental Variables: Device: Flame Master Build ID: 20140807084328 Gaia: 54c3c19d439f7dbafda5c6cc3b4850b545a068ba Gecko: 2f198e81ed98 Version: 34.0a1 (Master) Firmware Version: v123
QA Whiteboard: [QAnalyst-Triage?]
status-b2g-v2.1: --- → unaffected
QA Contact: croesch
This is certainly fixed in the latest. Seems like a works-for-me issue but I'll leave it alone because I'm not sure if you guys are trying to fix issues in 1.3?
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Let's close it, we won't provide a patch for this. If partners want to fix this, it should be easy to do that by themselves following comment 11. Thanks Joshua !
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → WORKSFORME
Dear Julien, I think this problem is lead by the press of the button on the header again during its page slide from right to right and before it on a stable status. It should be disable during this time.
The back button will slide from left to right, click on a message on the thread_list_ui will slide from right to left. If we press them in very short slot, they will collision. This will lead the bug.
Dear Tianm, there are a several fixes to this. What you say is not false, but I think it's a wrong fix. If a user wants to move back to the Thread List as soon as he enters a Thread, I think we should not prevent it. As I said, the easiest fix is comment 11.
You need to log in before you can comment on or make changes to this bug.