WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
129458
Web Inspector: Find in source does not find all results with non-unix line endings
https://bugs.webkit.org/show_bug.cgi?id=129458
Summary
Web Inspector: Find in source does not find all results with non-unix line en...
Timothy Hatcher
Reported
2014-02-27 15:54:20 PST
ContentSearchUtilities lineEndings only supports \n. That causes issues with non-unix line endings since the front-end supports \n, \r or \r\n <
rdar://problem/15829887
>
Attachments
Patch
(12.33 KB, patch)
2014-02-27 16:02 PST
,
Timothy Hatcher
no flags
Details
Formatted Diff
Diff
Patch
(12.71 KB, patch)
2014-02-27 16:31 PST
,
Timothy Hatcher
no flags
Details
Formatted Diff
Diff
Show Obsolete
(1)
View All
Add attachment
proposed patch, testcase, etc.
Radar WebKit Bug Importer
Comment 1
2014-02-27 15:54:32 PST
<
rdar://problem/16190305
>
Radar WebKit Bug Importer
Comment 2
2014-02-27 15:55:17 PST
<
rdar://problem/16190323
>
Timothy Hatcher
Comment 3
2014-02-27 16:02:09 PST
Created
attachment 225424
[details]
Patch
Joseph Pecoraro
Comment 4
2014-02-27 16:17:27 PST
Comment on
attachment 225424
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=225424&action=review
r=me
> Source/JavaScriptCore/ChangeLog:3 > + Imporve how ContentSearchUtilities::lineEndings works by supporting the three common line endings.
Typo: Imporve
> Source/JavaScriptCore/inspector/ContentSearchUtilities.cpp:91 > size_t lineEnd = endings->at(lineNumber); > String line = text.substring(start, lineEnd - start);
These variable names are misleading. endings->at(lineNumber) is actually giving you the index of the first character on lineNumber+1. Maybe that the way I think about it. I would expect "lineEnd" to be a character on this line, but here it is not.
> Source/JavaScriptCore/inspector/ContentSearchUtilities.cpp:116 > { > auto result = std::make_unique<Vector<size_t>>(); > > - unsigned start = 0; > + size_t start = 0; > while (start < text.length()) { > - size_t lineEnd = text.find('\n', start); > - if (lineEnd == notFound) > + size_t nextStart = text.findNextLineStart(start); > + if (nextStart == notFound) { > + result->append(text.length()); > break; > + } > > - result->append(lineEnd); > - start = lineEnd + 1; > + result->append(nextStart); > + start = nextStart;
Alongside the earlier comment, the function is named "lineEndings" but it returns the indexes that start the next line / EOF. I'm fine with the patch as is, but it might be clearer with better names.
> LayoutTests/inspector-protocol/debugger/searchInContent-linebreaks.html:65 > +Verify that Debugger.searchInContent works with scripts that have varying line endings.
Nit: Double space "varying line endings"
Timothy Hatcher
Comment 5
2014-02-27 16:31:49 PST
Created
attachment 225426
[details]
Patch
WebKit Commit Bot
Comment 6
2014-02-27 17:12:06 PST
Comment on
attachment 225426
[details]
Patch Clearing flags on attachment: 225426 Committed
r164845
: <
http://trac.webkit.org/changeset/164845
>
WebKit Commit Bot
Comment 7
2014-02-27 17:12:09 PST
All reviewed patches have been landed. Closing bug.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug