I suppose there's always a possibility, but I'm not aware of anything that would cause it to reject today. As a fallback, you could parse the major version from `navigator.userAgentData.brands`, or just grab that info from `navigator.userAgent` (the major version will always be there, even after the UA is fully reduced).

On 9/9/21 5:10 PM, Vladimir Pastukhov wrote:
Hi Mike

Sorry, missed this new method. Is there a possibility that the Promise will be rejected when invoked from the extension? Thanks.

On Friday, September 10, 2021 at 1:51:05 AM UTC+5 [email protected] wrote:

    Hi Vladimir,

    Can you help me understand why the JS API (e.g.,
    `navigator.userAgentData.getHighEntropyValues(["uaFullVersion"])`)
    won't work in a web extension?

    thanks,
    Mike

    On 9/9/21 4:48 PM, Vladimir Pastukhov wrote:
    *Hi, what about web extensions?*
    *
    *
    *How the extension developers are supposed to implement
    version-specific behavior after this change? Not every feature
    can be easily detected by testing objects for properties. Also
    sometimes we need the browser's full version to work around bugs
    in particular builds. And obviously, extensions can't use UA-CH *
    thing.

    On Wednesday, May 19, 2021 at 4:27:48 PM UTC+5
    [email protected] wrote:

        **

        *Hi there blink-dev and Chromium community,*

        *

        I’d like to give an update on our current thinking and plans
        around User-Agent Reduction (née “User Agent Freezing”) and
        provide a space for constructive feedback on the plans. For
        those looking for concrete timelines or Chrome versions—we’re
        not quite there yet—but will update this thread when we feel
        more confident on timing. What we can say at this time is
        that no UA string changes are coming to the stable channel of
        Chrome in 2021.


        The last major update we had on the topic was approximately a
        year ago
        
<https://groups.google.com/a/chromium.org/g/blink-dev/c/-2JIRNMWJ7s/m/u-YzXjZ8BAAJ>,
        where we announced a pause for two reasons: 1) the desire to
        not create an inconvenient migration burden on the web
        ecosystem during the early days of the COVID pandemic, and 2)
        to allow us to ship the User-Agent Client Hints API
        <https://web.dev/user-agent-client-hints/>(UA-CH), which is
        our proposed replacement for UA string-based content
        negotiation and detection.


        It took slightly longer than anticipated (due to unforeseen
        web compatibility issues
        <https://bugs.chromium.org/p/chromium/issues/detail?id=1149575#c2>),
        but UA-CH has been shipping and enabled
        <https://www.chromestatus.com/feature/5995832180473856>by
        default since M89. We’re also starting the roll-out of both
        Client Hints Reliability mechanisms (Critical-CH
        <https://chromestatus.com/feature/5727177800679424>&
        ACCEPT_CH
        <https://chromestatus.com/feature/5555544540577792>) to
        address use cases where hints are needed on the first request
        and hope for those features to be enabled in Chrome by
        default in M91 (note that some server-side work may need to
        be done by sites to take advantage of ACCEPT_CH). We also
        have proposed some UA-CH API updates
        
<https://groups.google.com/a/chromium.org/g/blink-dev/c/dafizBGwWMw/m/72l-1zm6AAAJ>
        we would like to prototype and ship.


        High-level Plan

        We intend to proceed with UA Reduction as follows:


        1.

            Beginning in M92, start sending deprecation/reduction
            notices for the navigator.userAgent,
            navigator.appVersion, and navigator.platform getters in
            the DevTools Issues tab
            <https://developer.chrome.com/docs/devtools/issues/>.

        2.

            In the coming weeks, we will send an Intent to Experiment
            to announce an Origin Trial (OT) for sites to opt into a
            Reduced UA String so that we can get feedback on the
            feasibility and compatibility of our desired end state.
            We expect to run an OT for at least 6 months to provide
            plenty of time for sites to opt in, test, and provide
            feedback.

        3.

            Evaluate feedback from OT partners and the community, and
            based on this feedback proceed to Phases 3 through 7 of
            our plan (see next section for details), giving the
            ecosystem plenty of time to adapt in between them.
            Otherwise, reconsider the best course of action depending
            on feedback.

        4.

            For sites with complex use cases that require more time
            for migration, we aim to offer the ability to extend the
            current User-Agent behavior for at least an additional 6
            months (through a reverse Origin Trial).


        Proposed changes

        We think it's best to roll this out slowly and incrementally
        in 7 Phases, pending Origin Trial feedback. As mentioned
        previously, we hope to publish an update soon on proposed
        timing and milestones for each of these Phases:


        Reduction Preparation


        Phase 1:Warn about accessing navigator.userAgent,
        navigator.appVersion, and navigator.platform in DevTools

        Phase 2:Launch an Origin Trial for sites to opt into the
        final reduced UA string for testing and feedback, for at
        least 6 months.


        Reduction Rollout


        Phase 3: Launch a reverse Origin Trial, for instances where a
        site may need more time for migration, for at least 6 months.

        Phase 4:Ship reduced Chrome MINOR.BUILD.PATCH version
        (“0.0.0”). Once rolled-out, the reduced UA string would apply
        to all page loads on desktop and mobile OSes that do not opt
        into the reverse OT.

        Phase 5:Begin roll-out of reduced Desktop UA string and
        navigator.platform. Once rolled-out, the reduced UA string
        would apply to all page loads on desktop OSes that do not opt
        into the reverse OT.

        Phase 6:Begin roll-out of reduced Android Mobile (and Tablet)
        UA string and navigator.platform.  Once rolled-out, the
        reduced UA string would apply to all page loads on Android
        that do not opt into the reverse OT.


        Reduction Completion


        Phase 7:reverse OT ends and all page loads receive the
        reduced UA string.


        See the reference page on chromium.org
        <https://www.chromium.org/updates/ua-reduction>which details
        all the actual User-Agent/navigator.userAgent changes at each
        phase, as well as values for navigator.platform and
        navigator.appVersion.


        Note: We have no plans to change the User-Agent string on
        Android WebView or Chrome for iOS at this time, but will make
        public updates if and when that changes.


        We realize that these proposed changes have raised many valid
        questions and concerns, and we appreciate the feedback we’ve
        gotten thus far. Please keep the feedback coming! As we
        continue to discuss the proposal, we ask everyone to be
        mindful of the Chromium Code of Conduct
        
<https://chromium.googlesource.com/chromium/src/+/master/CODE_OF_CONDUCT.md>.


        Thanks,

        Mike

        *


--
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/b71006fc-0070-5a4e-b339-2823b1f232a2%40chromium.org.

Reply via email to