Bug 52059

Summary: setContentEditable should be case insensitive
Product: WebKit Reporter: Chang Shu <cshu>
Component: HTML EditingAssignee: Chang Shu <cshu>
Status: RESOLVED DUPLICATE    
Severity: Normal CC: ademar, ap, darin, suresh.voruganti
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: PC   
OS: OS X 10.5   
Bug Depends on: 51957, 53010    
Bug Blocks:    
Attachments:
Description Flags
patch for QtWebKit2.1.x only! none

Description Chang Shu 2011-01-07 07:23:31 PST
The current implementation of setContentEditable does not take case insensitive into consideration.
Layout test:
set-value-caseinsensitive.html
Comment 1 Suresh Voruganti 2011-01-07 10:16:08 PST
Fix required for Qtwebkit 2.2
Comment 2 Alexey Proskuryakov 2011-01-07 10:33:22 PST
> set-value-caseinsensitive.html

Where can one find this layout test?
Comment 3 Chang Shu 2011-01-19 12:47:07 PST
document.getElementById("div1").contentEditable = "TRue";

1. shouldBe('document.getElementById("div1").getAttribute("contentEditable")','"TRue"');
2. shouldBe('document.getElementById("div1").getAttribute("contentEditable")','"true"');

I am not sure in the above tests, which one should be correct. I mean, should the attribute preserve the original string or should it convert to lower-case? Darin, can you help me? thanks!
Comment 4 Darin Adler 2011-01-19 13:23:58 PST
The HTML5 specification says convert to lowercase. That’s what we should implement.
Comment 5 Chang Shu 2011-01-27 11:57:28 PST
The case sensitive issue has been fixed with bug 52057. The remaining issue is identical to 52058.

*** This bug has been marked as a duplicate of bug 52058 ***
Comment 6 Chang Shu 2011-01-28 07:38:38 PST
Created attachment 80450 [details]
patch for QtWebKit2.1.x only!

This is a patch for QtWebKit2.1.x cherry-picking. DO NOT land in trunk.
Comment 7 Chang Shu 2011-01-28 07:40:48 PST
Ademar, can you cherry-pick this patch to QtWebKit2.1.x? thanks!
Comment 8 Ademar Reis 2011-01-28 10:34:20 PST
(In reply to comment #7)
> Ademar, can you cherry-pick this patch to QtWebKit2.1.x? thanks!

I'm confused:

1. This bug is closed as a duplicate of bug 52058;
2. Bug 52058 is open and also depends on bug 52025.

The right thing to do is to handle bug 52058 instead of this one, but it should be fixed on trunk before it's cherry-picked.
Comment 9 Chang Shu 2011-01-28 10:39:01 PST
(In reply to comment #8)
> (In reply to comment #7)
> > Ademar, can you cherry-pick this patch to QtWebKit2.1.x? thanks!
> 
> I'm confused:
> 
> 1. This bug is closed as a duplicate of bug 52058;
> 2. Bug 52058 is open and also depends on bug 52025.
> 
> The right thing to do is to handle bug 52058 instead of this one, but it should be fixed on trunk before it's cherry-picked.

I just re-use this bug for submitting this patch. The test cases in this patch are failing on trunk but pass on 2.1.x (I think trunk has a regression, but it will be fixed by 52058). Since 2.1.x is working fine, all this patch does is rebaseline the test results.
Comment 10 Ademar Reis 2011-01-28 11:09:42 PST
(In reply to comment #9)
> (In reply to comment #8)
> > (In reply to comment #7)
> > > Ademar, can you cherry-pick this patch to QtWebKit2.1.x? thanks!
> > 
> > I'm confused:
> > 
> > 1. This bug is closed as a duplicate of bug 52058;
> > 2. Bug 52058 is open and also depends on bug 52025.
> > 
> > The right thing to do is to handle bug 52058 instead of this one, but it should be fixed on trunk before it's cherry-picked.
> 
> I just re-use this bug for submitting this patch. The test cases in this patch are failing on trunk but pass on 2.1.x (I think trunk has a regression, but it will be fixed by 52058). Since 2.1.x is working fine, all this patch does is rebaseline the test results.

OK, got it. Patch added to 2.1.x: 71743851334e7dabe9380d9ab5a4f597144f94c0

Thanks.