617a30f35e
This was automated using a script [1] that does the following: - Rename relevant files in the following folders from website_settings* to page_info*: - chrome/browser/ui/page_info - chrome/browser/ui/cocoa/page_info - chrome/browser/ui/views/page_info - chrome/browser/ui/android/page_info - chrome/android/java/res/layout - Run `./tools/git/mass-rename.py` to update e.g. includes, build files, header guards. - mass-rename.py does not handle test files (https://crbug.com/701529) or Java, so those are handled separately, either in an early step are as part of the later renames. - `page_info_bubble_controller.h` needs a separate header guard fix. - Use `sed` to rename classes, enums, non-UMA strings, and comments *WebsiteSettings* to *PageInfo* across the entire Chromium project. - Since several content settings classes are also called "WebsiteSettings", this is done by taking a full list of all occurrences of full tokens containing "WebsiteSettings", "website_settings", or "website settings" and whitelisting individual replacements. - To avoid modifying strings, all lines containing the relevant tokens *following at least one quote mark on the same line* are preserved, except two individually handled cases. There do not appear to be any affected multi-line strings. - `git cl format` - Remove two long-standing TODO comments about this rename, in: - PageInfoPopup.java - page_info_bubble_controller.h This CL does not attempt to reflow comments; all changes stay within 80 lines, though. [1] https://github.com/lgarron/website-settings-to-page-info/blob/master/page_info.fish BUG=571506 TBR=jochen@chromium.org Review-Url: https://codereview.chromium.org/2754383004 Cr-Commit-Position: refs/heads/master@{#459562}
86 lines
3.4 KiB
Markdown
86 lines
3.4 KiB
Markdown
# MacViews Release Plan
|
|
|
|
## Handy Links
|
|
|
|
* [Phase 1 bugs](https://bugs.chromium.org/p/chromium/issues/list?can=2&q=Proj%3DMacViews+label%3Aphase1&colspec=ID+Pri+M+Stars+ReleaseBlock+Component+Status+Owner+Summary+OS+Modified&x=m&y=releaseblock&cells=ids)
|
|
* [Phase 2 bugs](https://bugs.chromium.org/p/chromium/issues/list?can=2&q=Proj%3DMacViews+label%3Aphase2&colspec=ID+Pri+M+Stars+ReleaseBlock+Component+Status+Owner+Summary+OS+Modified&x=m&y=releaseblock&cells=ids)
|
|
* [Other MacViews bugs](https://bugs.chromium.org/p/chromium/issues/list?can=2&q=Proj%3DMacViews+-label%3APhase1+-label%3APhase2&colspec=ID+Pri+M+Stars+ReleaseBlock+Component+Status+Owner+Summary+OS+Modified&x=m&y=releaseblock&cells=ids)
|
|
* [Catalog of chromium dialogs](https://docs.google.com/spreadsheets/d/1rChQOblJDsXevMxpUpvaPqK3QIMPdmd2iAvJtdeOeeY/edit#gid=0)
|
|
|
|
## Phase 1: Controls
|
|
|
|
Implement Shiny Modern L&F for individual controls, most-commonly-used first. In
|
|
rough order:
|
|
|
|
1. Buttons
|
|
2. Editboxes
|
|
3. Comboboxes
|
|
4. Radiobuttons/checkboxes
|
|
5. Menubuttons
|
|
6. Treeviews
|
|
7. Tableviews
|
|
|
|
This phase overlaps with phase 2.
|
|
|
|
## Phase 2: WebUI Cocoa Dialogs, Rubberband
|
|
|
|
Once enough controls are done, wire up the Views versions of WebUI-styled Cocoa
|
|
dialogs, behind a new `MacViewsWebUIDialogs` feature. The WebUI-styled Cocoa
|
|
dialogs are:
|
|
|
|
1. Collected/blocked cookies UI
|
|
2. Device permissions
|
|
3. Extension install
|
|
4. HTTP auth
|
|
5. One-click signin
|
|
6. Site permissions bubble
|
|
7. "Card unmask prompt" (TODO(ellyjones): what is this?)
|
|
8. Page info dialog
|
|
|
|
Once all of these dialogs are converted and tested behind the feature, we can
|
|
ship to canary and dev channels and watch for any performance or crash rate
|
|
regressions. Doing all the WebUI-style dialogs at once will avoid having three
|
|
separate dialog UIs.
|
|
|
|
This phase also includes implementation of rubber-band overscroll and fling
|
|
scrolling. This technology exists already in the renderer compositor - it needs
|
|
to be transplanted to the ui compositor.
|
|
|
|
## Phase 3: The Other Dialogs
|
|
|
|
Once WebUI dialogs are converted en masse, we can convert other dialogs to Views
|
|
individually, and ship them without a flag flip or field trial. Cocoa dialogs
|
|
that are in native Cocoa style will gradually migrate to Views dialogs that are
|
|
in the Shiny Modern style.
|
|
|
|
## Phase 4: Omnibox & Top Chrome
|
|
|
|
At this point, all dialogs are in Shiny Modern, but the rest of the browser
|
|
chrome is still Cocoa.
|
|
|
|
Implement Cocoa L&F for any controls still needed for omnibox and top chrome.
|
|
TODO(ellyjones): which controls are these?
|
|
Implement Views versions of the omnibox and top chrome behind a new flag
|
|
`mac-views-browser-chrome`.
|
|
Get UI review of the new versions of the omnibox and top chrome.
|
|
Make the Views versions the default.
|
|
|
|
## Phase 5: `mac_views_browser=1`
|
|
At this point, all user-visible UI is done via Views, and we need to switch the
|
|
entire browser to a Views-only build:
|
|
|
|
Check for performance regressions against `mac_views_browser=0`.
|
|
Check for stability regressions against `mac_views_browser=0`.
|
|
Check for a11y regressions through manual testing.
|
|
TODO(ellyjones): Figure out how feasible automated a11y regression testing is.
|
|
Switch `mac_views_browser` to 1 for Canary.
|
|
Cross fingers.
|
|
Watch metrics carefully.
|
|
If there's no surprising metrics changes or public outcry, keep
|
|
mac_views_browser=1 for dev, then beta, then stable.
|
|
|
|
## Phase 6: delete Cocoa
|
|
Since much of the Cocoa code is dead and we are no longer building with
|
|
`mac_views_browser=0`, remove dead Cocoa UI code.
|
|
|