| Summary: | REGRESSION(r166395): It made all media tests crash on EFL | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | WebKit | Reporter: | Csaba Osztrogonác <ossy> | ||||||
| Component: | Media | Assignee: | Nobody <webkit-unassigned> | ||||||
| Status: | REOPENED --- | ||||||||
| Severity: | Blocker | CC: | bfulgham, commit-queue, darin, eric.carlson, esprehn+autocc, glenn, gyuyoung.kim, gyuyoung.kim, jer.noble, ossy, philipj, pulkomandy, ryuan.choi, sergio | ||||||
| Priority: | P1 | ||||||||
| Version: | 528+ (Nightly build) | ||||||||
| Hardware: | Unspecified | ||||||||
| OS: | Unspecified | ||||||||
| Bug Depends on: | 131257 | ||||||||
| Bug Blocks: | 130882 | ||||||||
| Attachments: |
|
||||||||
|
Description
Csaba Osztrogonác
2014-04-01 09:57:47 PDT
Created attachment 228389 [details]
backtrace
Here is a gdb backtrace for media/audio-concurrent-supported.html,
it might help someone interested in fixing this regression.
My question is why EFL uses MediaControlsApple.cpp?
(In reply to comment #1) > Created an attachment (id=228389) [details] > backtrace > > Here is a gdb backtrace for media/audio-concurrent-supported.html, > it might help someone interested in fixing this regression. More information, This crash is started from r166395 ( Bug 130882 ). But I am not sure why it occurs in EFL because it is general code. > > My question is why EFL uses MediaControlsApple.cpp? EFL may need to have own MediaControls but it looks not related to this issue. We have the same problem in the Haiku port (also using MediaControlsApple.cpp). Moving the setPseudo call to the create methods, after the call to setType, seems to work around this, but I don't know if that's the proper fix. Here is our patch for this: https://github.com/haiku/webkit/commit/1a7810025da941981a6e39cc4b199eb47615e0c2 (In reply to comment #2) > (In reply to comment #1) > > Created an attachment (id=228389) [details] [details] > > backtrace > > > > Here is a gdb backtrace for media/audio-concurrent-supported.html, > > it might help someone interested in fixing this regression. > > More information, > This crash is started from r166395 ( Bug 130882 ). > But I am not sure why it occurs in EFL because it is general code. At least, I realized that GTK and (maybe) MAC does not use this crash path because they use MEDIA_CONTROLS_SCRIPT. Just for test, I tried to use the code of GTK port. And media/audio-concurrent-supported.html is passed. (control is bit ugly for efl port) IMO, we should turn on the MEDIA_CONTROLS_SCRIPT. but I am not sure whether it is correct solution for this crash. Anyway, I will prepare proper css/js for EFL port. (It may takes more time) It seems the EFL bots are still broken from this regression. (during ~500 revisions and 11 days) Is there any plan to fix them to be able catch new regressions again? (In reply to comment #6) > It seems the EFL bots are still broken from this regression. > (during ~500 revisions and 11 days) > > Is there any plan to fix them to be able catch new regressions again? Yes, EFL bots have broken too long time. I couldn't take a look this problem due to my various works. Let me try to fix it as soon as possible. Almost media tests are being passed on EFL buildbot. However, unfortunately I failed to find what revision fixed this issue. To maintain those test on EFL port again, I unskip it by r173864. http://trac.webkit.org/changeset/173864 (In reply to comment #8) > Almost media tests are being passed on EFL buildbot. However, unfortunately I failed to find what revision fixed this issue. To maintain those test on EFL port again, I unskip it by r173864. > > http://trac.webkit.org/changeset/173864 Not at all, all media tests still fail on the EFL bot and this unskipping made the runtime from 22mins to 3.5hours and the number of failing test from 30-40 to 300+. :-/ (In reply to comment #9) > (In reply to comment #8) > > Almost media tests are being passed on EFL buildbot. However, unfortunately I failed to find what revision fixed this issue. To maintain those test on EFL port again, I unskip it by r173864. > > > > http://trac.webkit.org/changeset/173864 > > Not at all, all media tests still fail on the EFL bot and this > unskipping made the runtime from 22mins to 3.5hours and the > number of failing test from 30-40 to 300+. :-/ Ossy, something is weird. When I test it locally, there were dozens of failing tests. Let me check it again. Created attachment 239541 [details]
Patch
Brent, Eric, Jer, could one of you review this? One thing I am noticing is that if the setPseudo calls are now moved after the elements are completely constructed, we could possibly go back to calling shadowPseudoId() rather than separately hardcoding each ID. I suspect the reason that didn’t work before is that we were calling it during construction. I think it would be helpful if someone would state what the fix is meant to do. It looks like the issue is that the 'setPseudo' call in the constructor causes an error when the m_innerText of a TextFieldInputType class is accessed. Apparently this does not yet exist during construction time. It seems strange to have to set these attributes of the class after construction, but I guess it's no worse than the existing need to call 'setType' or 'ensureUserAgentShadowRoot' after the object is constructed. This seems like clunky design, but I'm not sure how to address it at this point. (In reply to comment #13) > I think it would be helpful if someone would state what the fix is meant to do. > > It looks like the issue is that the 'setPseudo' call in the constructor causes an error when the m_innerText of a TextFieldInputType class is accessed. Apparently this does not yet exist during construction time. Yeah, if you're calling a virtual method (Element::attributeChanged()) from a constructor you're going to have a bad time. (<meme>) > It seems strange to have to set these attributes of the class after construction, but I guess it's no worse than the existing need to call 'setType' or 'ensureUserAgentShadowRoot' after the object is constructed. > > This seems like clunky design, but I'm not sure how to address it at this point. I don't think there's a better way. (In reply to comment #12) > Brent, Eric, Jer, could one of you review this? > > One thing I am noticing is that if the setPseudo calls are now moved after the elements are completely constructed, we could possibly go back to calling shadowPseudoId() rather than separately hardcoding each ID. I suspect the reason that didn’t work before is that we were calling it during construction. Someone added a FIXME to shadowPseudoId() asking clients not to overload it. So I don't think we should go back to using it instead. Comment on attachment 239541 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=239541&action=review > Source/WebCore/ChangeLog:9 > + No new tests: fixes existing tests. > + The pseudo id cannot be set before the elements get a type. The patch is not necessarily wrong, but the changelog is unsatisfactory. Here you should explain exactly why the crash occur and why this is the right fix for it. The media tests are still skipped. Is EFL port interested in fixing this old regression? (In reply to comment #17) > The media tests are still skipped. Is EFL port interested in fixing this old > regression? Now media tests are passed on EFL port, except for 25 tests. I update this result in r182657 - http://trac.webkit.org/changeset/182657. |