Bug 135341 - Web Replay: vectors of characters should be base64-encoded
Summary: Web Replay: vectors of characters should be base64-encoded
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebCore Misc. (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Brian Burg
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-07-28 11:08 PDT by Brian Burg
Modified: 2014-07-28 14:31 PDT (History)
5 users (show)

See Also:

Attachments
Patch (2.71 KB, patch)
2014-07-28 11:27 PDT, Brian Burg 		no flags Details | Formatted Diff | Diff
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Brian Burg 2014-07-28 11:08:06 PDT 
Add this specialization separately since at least two replay features (resource loading, navigations) depend on it.
Comment 1 Brian Burg 2014-07-28 11:27:04 PDT 
Created attachment 235600 [details]
Patch
Comment 2 WebKit Commit Bot 2014-07-28 12:21:38 PDT 
Comment on attachment 235600 [details]
Patch

Clearing flags on attachment: 235600

Committed r171682: <http://trac.webkit.org/changeset/171682>
Comment 3 WebKit Commit Bot 2014-07-28 12:21:41 PDT 
All reviewed patches have been landed.  Closing bug.
Comment 4 Mark Hahnenberg 2014-07-28 13:46:54 PDT 
(In reply to comment #2)
> (From update of attachment 235600 [details])
> Clearing flags on attachment: 235600
> 
> Committed r171682: <http://trac.webkit.org/changeset/171682>

Looks like this broke the build.
Comment 5 Mark Hahnenberg 2014-07-28 13:47:34 PDT 
(In reply to comment #4)
> (In reply to comment #2)
> > (From update of attachment 235600 [details] [details])
> > Clearing flags on attachment: 235600
> > 
> > Committed r171682: <http://trac.webkit.org/changeset/171682>
> 
> Looks like this broke the build.

See, e.g. http://build.webkit.org/builders/Apple%20Mavericks%2032-bit%20JSC%20%28BuildAndTest%29/builds/3167
Comment 6 Brian Burg 2014-07-28 14:10:43 PDT 
(In reply to comment #5)
> (In reply to comment #4)
> > (In reply to comment #2)
> > > (From update of attachment 235600 [details] [details] [details])
> > > Clearing flags on attachment: 235600
> > > 
> > > Committed r171682: <http://trac.webkit.org/changeset/171682>
> > 
> > Looks like this broke the build.
> 
> See, e.g. http://build.webkit.org/builders/Apple%20Mavericks%2032-bit%20JSC%20%28BuildAndTest%29/builds/3167

Landed a fix in <http://trac.webkit.org/changeset/171694>. Still not sure why the build break cannot reproduce locally or on EWS...
Comment 7 Mark Hahnenberg 2014-07-28 14:11:21 PDT 
(In reply to comment #6)
> (In reply to comment #5)
> > (In reply to comment #4)
> > > (In reply to comment #2)
> > > > (From update of attachment 235600 [details] [details] [details] [details])
> > > > Clearing flags on attachment: 235600
> > > > 
> > > > Committed r171682: <http://trac.webkit.org/changeset/171682>
> > > 
> > > Looks like this broke the build.
> > 
> > See, e.g. http://build.webkit.org/builders/Apple%20Mavericks%2032-bit%20JSC%20%28BuildAndTest%29/builds/3167
> 
> Landed a fix in <http://trac.webkit.org/changeset/171694>. Still not sure why the build break cannot reproduce locally or on EWS...

Might be 32-bit specific? *shrugs*
Comment 8 Brian Burg 2014-07-28 14:31:46 PDT 
Still didn't fix it. It seems this is the first use of base64encode() from a header. Looking at Base64.h, there are 4 adapters and 2 actual implementations, but all are marked WTF_EXPORT_PRIVATE. Since EncodedValue.h is included multiple places, it will trigger weak symbol problems that seem to have been latent in that header.