RESOLVED FIXED 96619
[EFL] REGRESSION (r128274): fast/overflow/overflow-height-float-not-removed-crash.html 
https://bugs.webkit.org/show_bug.cgi?id=96619
Summary [EFL] REGRESSION (r128274): fast/overflow/overflow-height-float-not-removed-c...
Mikhail Pozdnyakov
Reported 2012-09-13 01:05:15 PDT
fast/overflow/overflow-height-float-not-removed-crash.html is crashing after r128274
Attachments
patch (2.76 KB, patch)
2012-09-13 01:52 PDT, Mikhail Pozdnyakov 		no flags
DetailsFormatted DiffDiff
View All Add attachment proposed patch, testcase, etc.
Mikhail Pozdnyakov
Comment 1 2012-09-13 01:52:19 PDT
Created attachment 163817 [details] patch
Kenneth Rohde Christiansen
Comment 2 2012-09-13 02:05:58 PDT
Comment on attachment 163817 [details] patch It is fine, but did you look into why it was failing to create?
WebKit Review Bot
Comment 3 2012-09-13 02:10:42 PDT
Comment on attachment 163817 [details] patch Clearing flags on attachment: 163817 Committed r128431: <http://trac.webkit.org/changeset/128431>
WebKit Review Bot
Comment 4 2012-09-13 02:10:46 PDT
All reviewed patches have been landed. Closing bug.
Mikhail Pozdnyakov
Comment 5 2012-09-13 02:59:17 PDT
(In reply to comment #2) > (From update of attachment 163817 [details]) > It is fine, but did you look into why it was failing to create? The size argument was too big
Kenneth Rohde Christiansen
Comment 6 2012-09-13 04:15:01 PDT
(In reply to comment #5) > (In reply to comment #2) > > (From update of attachment 163817 [details] [details]) > > It is fine, but did you look into why it was failing to create? > > The size argument was too big OK then, does that mean that we just doesn't cache it and are still painting it? Or are we not painting it in that case?
Mikhail Pozdnyakov
Comment 7 2012-09-13 04:41:28 PDT
(In reply to comment #6) > (In reply to comment #5) > > (In reply to comment #2) > > > (From update of attachment 163817 [details] [details] [details]) > > > It is fine, but did you look into why it was failing to create? > > > > The size argument was too big > > OK then, does that mean that we just doesn't cache it and are still painting it? Or are we not painting it in that case? entry = getThemePartFromCache(type, rect.size()); if (!entry) return false; I guess, it won't be painted
Kenneth Rohde Christiansen
Comment 8 2012-09-13 04:48:31 PDT
> I guess, it won't be painted That is what I guessed. Maybe we should look into that? and adds some efl tests?
Note You need to log in before you can comment on or make changes to this bug.