Serve mainPageSuffix File Without Redirecting to It [151713401]

Assigned

Feature Request

Status Update

No update yet.

Description

ad...@avantsoft.com.br

created issue #1

Mar 17, 2020 04:46PM

Not sure if I consider this a bug report or a feature request. Regardless, follows description below:

Problem you have encountered:
If a user sets a bucket to serve a website with the command `gsutil web set -m index.html gs://

my-bucket.com` they can access `

my-bucket.com` and the `index.html` at the root of the bucket will be served without changing the URL. This behavior is expected and awesome.

Naturally, this extends to a user attempting to access a subdirectory such as `

my-bucket.com/my-favorite-directory/`. Again, very useful.

However, if the user does not add the `/` in the end of the subdirectory the behavior changes! Instead of being served the `index.html` from the corresponding directory the user is redirected to the corresponding `index.html` file. So they would then see in the browser `

my-bucket.com/my-favorite-directory/index.html`.

This breaks the ability of using GCP's buckets for serving pre-rendered SPA applications (without having to duplicate all index.html files in directories).

What you expected to happen:
I expect the respective `index.html` (the mainPageSuffix file) to be served without redirecting (HTTP 301) to it. Or (feature request) that the redirecting versus just serving be configurable (assuming there are users that use this redirect capability).

Other information (workarounds you have tried, documentation consulted, etc):
1. Duplicate `index.html` files up 1 directory. Ex: If you have a /directory/index.html also have a /directory file (named the same as the directory).
2. Add JS to redirect user if /index.html is ever found in the end of the URL (not sure what the SEO impact would be).
3. Use another solution instead of GCP's storage bucket.

Comments

oq...@google.com <oq...@google.com> #2Mar 21, 2020 12:04AM

Status: Won't Fix (Intended Behavior)

Thanks for the report. I will route this to the appropriate internal team and update this when I hear back from them.

ad...@avantsoft.com.br <ad...@avantsoft.com.br> #3Mar 22, 2020 06:00PM

One more detail, Data Layer event calls from the watch to the phone (running Android 13) do work on if the listener is in an Activity or Fragment.

Message last modified on Mar 22, 2020 06:00PM

ka...@google.com <ka...@google.com> #4Jun 1, 2021 10:21AM

Also, I'm seeing this message in the Logcat:

"2022-06-12 18:47:15.156 1841-4562/? W/PackageManager: Intent does not match component's intent filter: Intent { act=com.google.android.gms.wearable.BIND_LISTENER"

[Deleted User] <[Deleted User]> #5Jun 15, 2021 06:31AM

Experiencing the same issues, please see my other report for any useful logs:

https://issuetracker.google.com/issues/235673375

fr...@gmail.com <fr...@gmail.com> #6Jul 20, 2021 01:43AM

+1, can confirm it doesn't work on Android 13:=

2022-07-15 11:26:15.023   589-5347  PackageManager          pid-589                              W  Intent does not match component's intent filter: Intent { act=com.google.android.gms.wearable.BIND_LISTENER cmp=xxx/xxx.WatchMessageReceiver }
2022-07-15 11:26:15.023   589-5347  PackageManager          pid-589                              W  Access blocked: ComponentInfo{xxx/xxx.WatchMessageReceiver}
2022-07-15 11:26:15.023   589-5347  ActivityManager         pid-589                              W  Unable to start service Intent { act=com.google.android.gms.wearable.BIND_LISTENER cmp=xxx/xxx.WatchMessageReceiver } U=0: not found

co...@wizardsofindustry.com <co...@wizardsofindustry.com> #7Jul 25, 2021 08:17PM

Note that I've been able to make it work by:

Adding <action android:name="com.google.android.gms.wearable.BIND_LISTENER" /> in the intent filter
Removing <data android:scheme="wear" android:host="*" />

But I feel like this is not something we should do

mi...@blueshoe.de <mi...@blueshoe.de> #8Aug 26, 2021 06:32PM

I'm really afraid Android 13 might get released as-is, breaking WearOS app communication 😨😨

ko...@gmail.com <ko...@gmail.com> #9Oct 23, 2021 06:10AM

If you're not targeting API 33 you're not affected by the bug. So it's a big bug, and yes we of course expected more from Google, but you can always target the api level later when it's fixed.

But I agree this is kind of desperating that more than 1.5 month after the first report nothing has changed.

al...@altermeliora.com <al...@altermeliora.com> #10Nov 2, 2021 04:48PM

As an interim update on this issue: we've been already working on the fix that should be available by Android 13 release. The fix requires thorough testing, I'll keep this bug updated as soon as we have more to share. Thanks!

[Deleted User] <[Deleted User]> #11Nov 25, 2021 04:15PM

Comment has been deleted.

Message last modified on Nov 25, 2021 04:19PM

sc...@google.com <sc...@google.com> #12Apr 20, 2022 09:25AM

Status: Assigned (reopened)

Hey @

comment#10

, do you have any news to share?

Android 13 is out today and we still have no patch unlike what you said a month ago

pr...@greedygame.com <pr...@greedygame.com> #13Jul 7, 2022 09:17AM

I have no words for this. Android 13 is labeled "stable" but the Wearable API just doesn't work. Can't this issue be given higher priority? If you want to push WearOS you need to make sure it works normally.

al...@google.com <al...@google.com> Oct 5, 2022 11:26PM

Reassigned to do...@google.com.

is...@google.com <is...@google.com> Jan 25, 2023 10:19AM

Status: New

cl...@gmail.com <cl...@gmail.com> #14May 11, 2023 12:50PM

This issues has been already given high priority (updated external priority on this bug to reflect internal status). The fix is on the way and going through the final rounds of testing, so the roll out is slated to next couple of weeks.

To reiterate what have been mentioned earlier on this bug: this issue affects only apps targeting Android 13, so the apps won't break unless you bump targetSDK version to 33. In case if you want to start working on app compatibility for Android 13 behaviour changes, you could use Compatibility framework to toggle on/off the changes individually for isolated testing.

jo...@smirk.gg <jo...@smirk.gg> #15Jun 1, 2023 02:42PM

comment#14

as much as I agree that is not a blocking bug, you need to understand that:
- The report is 2 months old
- Google chose to release Android 13 with that bug
- There's no mention of this bug on the documentation so you can totally bump your targetSdk without noticing it

So thank you guys for working on this but it's still not a valid excuse for taking that long for such an important issue. Now that being said, let us know when a fix is available

sa...@riker.tech <sa...@riker.tech> #16Jun 10, 2023 08:04AM

Google will come through. They always do!

Message last modified on Jun 10, 2023 08:08AM

ga...@meufluxo.com <ga...@meufluxo.com> #17Jul 4, 2023 08:20PM

That must be some really intense testing as we are 10 days later and still nothing on sight. I don't want to be a P2 issue if that's what a P1 is.

ba...@google.com <ba...@google.com> Aug 1, 2023 11:58AM

Assigned to ku...@google.com.

ku...@google.com <ku...@google.com> Sep 8, 2023 06:14AM

Reassigned to gc...@google.com.

[Deleted User] <[Deleted User]> #18Sep 29, 2023 03:49AM