Bug 195630 - Web Inspector: Sources: allow image collections to be filtered by type
Summary: Web Inspector: Sources: allow image collections to be filtered by type
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Web Inspector (show other bugs)
Version: WebKit Nightly Build
Hardware: All All
: P2 Normal
Assignee: Devin Rousso
URL:
Keywords: InRadar
Depends on: 145906
Blocks:
  Show dependency treegraph
 
Reported: 2019-03-12 10:53 PDT by Devin Rousso
Modified: 2019-03-15 12:07 PDT (History)
6 users (show)

See Also:


Attachments
Patch (16.77 KB, patch)
2019-03-12 12:44 PDT, Devin Rousso
no flags Details | Formatted Diff | Diff
Patch (17.20 KB, patch)
2019-03-12 14:08 PDT, Devin Rousso
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Devin Rousso 2019-03-12 10:53:11 PDT
<https://bugs.webkit.org/show_bug.cgi?id=145906#c8>
Comment 1 Devin Rousso 2019-03-12 12:44:37 PDT
Created attachment 364428 [details]
Patch
Comment 2 Matt Baker 2019-03-12 13:28:58 PDT
Comment on attachment 364428 [details]
Patch

Could we avoid creating UIStrings for extensions? Extensions aren't localizable, and are commonly shown in both all uppercase/all lowercase, so I don't think we need to map "web" to "WebP", for example.

Instead of updating the hidden state of ScopeBarItems as resources change, could we rebuild the bar based on the available resources?
Comment 3 Matt Baker 2019-03-12 13:29:36 PDT
(In reply to Matt Baker from comment #2)
> Comment on attachment 364428 [details]
> Patch
> 
> Could we avoid creating UIStrings for extensions? Extensions aren't
> localizable, and are commonly shown in both all uppercase/all lowercase, so
> I don't think we need to map "web" to "WebP", for example.

"webp" to "WebP"
Comment 4 Devin Rousso 2019-03-12 13:42:30 PDT
(In reply to Matt Baker from comment #2)

> Could we avoid creating UIStrings for extensions? Extensions aren't localizable, and are commonly shown in both all uppercase/all lowercase, so I don't think we need to map "web" to "WebP", for example.
I would tend to agree, but @rniwa pointed out to me a few weeks ago that it's still necessary to make things like this a localized string so that languages that rarely (if ever) use English (like Japanese) would be able to transliterate.  In this case "WebP" isn't referring to the file extension, but rather the MIME "type", such as how 
JPG" holds both *.jpg and *.jpeg.

> Instead of updating the hidden state of ScopeBarItems as resources change, could we rebuild the bar based on the available resources?
I chose the hidden state approach because it was less of a major change given the current capabilities of `WI.ScopeBar`.  If we wanted to rebuild the bar, we'd need to support the ability to set a new list of `WI.ScopeBarItem`, which is probably harder to do considering that this is a `WI.NavigationItem` subclass (e.g. we'd have to update the `WI.ContentView`'s list of `navigationItems`, and fire an event to re-render).
Comment 5 Matt Baker 2019-03-12 14:04:07 PDT
(In reply to Devin Rousso from comment #4)
> (In reply to Matt Baker from comment #2)
> 
> > Could we avoid creating UIStrings for extensions? Extensions aren't localizable, and are commonly shown in both all uppercase/all lowercase, so I don't think we need to map "web" to "WebP", for example.
> I would tend to agree, but @rniwa pointed out to me a few weeks ago that
> it's still necessary to make things like this a localized string so that
> languages that rarely (if ever) use English (like Japanese) would be able to
> transliterate.  In this case "WebP" isn't referring to the file extension,
> but rather the MIME "type", such as how 
> JPG" holds both *.jpg and *.jpeg.

To the last point, if this is a list of "types" rather than extensions, should we use JPEG instead of JPG? After all, when going the other direction WI.mimeTypeForFileExtension maps "jpg" and "jpeg" to "image/jpeg". I'll leave it up to you.

> > Instead of updating the hidden state of ScopeBarItems as resources change, could we rebuild the bar based on the available resources?
> I chose the hidden state approach because it was less of a major change
> given the current capabilities of `WI.ScopeBar`.  If we wanted to rebuild
> the bar, we'd need to support the ability to set a new list of
> `WI.ScopeBarItem`, which is probably harder to do considering that this is a
> `WI.NavigationItem` subclass (e.g. we'd have to update the
> `WI.ContentView`'s list of `navigationItems`, and fire an event to
> re-render).

In the interest of treading lightly, that makes sense. It would still be nice to build the list of extensions/ScopeBarItems dynamically, so it isn't possible to skip an image type. Since the list looks like it was based on the mappings in WI.mimeTypeForFileExtension, I think it's fine.
Comment 6 Matt Baker 2019-03-12 14:04:41 PDT
Comment on attachment 364428 [details]
Patch

r=me, nice enhancement.
Comment 7 Devin Rousso 2019-03-12 14:08:59 PDT
Created attachment 364444 [details]
Patch
Comment 8 WebKit Commit Bot 2019-03-12 14:47:44 PDT
Comment on attachment 364444 [details]
Patch

Clearing flags on attachment: 364444

Committed r242829: <https://trac.webkit.org/changeset/242829>
Comment 9 WebKit Commit Bot 2019-03-12 14:47:45 PDT
All reviewed patches have been landed.  Closing bug.
Comment 10 Radar WebKit Bug Importer 2019-03-12 14:48:26 PDT
<rdar://problem/48824542>
Comment 11 Joseph Pecoraro 2019-03-15 11:41:34 PDT
Comment on attachment 364444 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=364444&action=review

> Source/WebInspectorUI/Localizations/en.lproj/localizedStrings.js:729
> +localizedStrings["PDF"] = "PDF";
> +localizedStrings["PNG"] = "PNG";

Is there any reason these file extensions should be localized? These seem like the perfect thing to not localize.
Comment 12 Matt Baker 2019-03-15 12:03:47 PDT
Comment on attachment 364444 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=364444&action=review

>> Source/WebInspectorUI/Localizations/en.lproj/localizedStrings.js:729
>> +localizedStrings["PNG"] = "PNG";
> 
> Is there any reason these file extensions should be localized? These seem like the perfect thing to not localize.

See Devin's comment regarding this: https://bugs.webkit.org/show_bug.cgi?id=195630#c4
Comment 13 Joseph Pecoraro 2019-03-15 12:07:21 PDT
(In reply to Matt Baker from comment #12)
> Comment on attachment 364444 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=364444&action=review
> 
> >> Source/WebInspectorUI/Localizations/en.lproj/localizedStrings.js:729
> >> +localizedStrings["PNG"] = "PNG";
> > 
> > Is there any reason these file extensions should be localized? These seem like the perfect thing to not localize.
> 
> See Devin's comment regarding this:
> https://bugs.webkit.org/show_bug.cgi?id=195630#c4

Okay, sounds good.