Fixed
Status Update
Comments
d....@gmail.com <d....@gmail.com> #2
Thank you for posting.
Kindly provide a sample app with screen recording and steps to reproduce for further checking.
am...@google.com <am...@google.com> #3
Thank for your help.
The issue is easily reproduced with the Stroke and Width settings for Buildings (3d and Footprint) within the latest Maps JavaScript API and both the old web-based Map Styles editor and the new cloud-based Map Styles editor. You can reproduce the issue by attempting to add an outline (stroke) of any width under Landscape-Human-made(man_made)-Buildings. The expected changes do not show in the rendered map within the Styles editor(s) or when loading the map via saved Map ID elsewhere.
I don't have time this week to author a screen recording that redacts my proprietary intellectual property, and I certainly won't be providing a copy of my software or authoring a sample app for you when you can already easily duplicate the bug in your own Map Styles editors.
I may have time to provide a marked-up screenshot from the Map Styles editor later tonight or tomorrow when I am back at my computer.
The issue is easily reproduced with the Stroke and Width settings for Buildings (3d and Footprint) within the latest Maps JavaScript API and both the old web-based Map Styles editor and the new cloud-based Map Styles editor. You can reproduce the issue by attempting to add an outline (stroke) of any width under Landscape-Human-made(man_made)-Buildings. The expected changes do not show in the rendered map within the Styles editor(s) or when loading the map via saved Map ID elsewhere.
I don't have time this week to author a screen recording that redacts my proprietary intellectual property, and I certainly won't be providing a copy of my software or authoring a sample app for you when you can already easily duplicate the bug in your own Map Styles editors.
I may have time to provide a marked-up screenshot from the Map Styles editor later tonight or tomorrow when I am back at my computer.
an...@gmail.com <an...@gmail.com> #4
Good morning,
To follow-up on this in an effort to assist you in bringing this bug to a resolution, please see the attached screenshot from the (old) Map Styles editor showing the issue and how you can duplicate it on your own. Similarly, the issue can also be duplicated in the (new) preview of the cloud-based Map Styles editor. Stroke color and width are not working as expected, for both the 3d and footprint style of buildings on the map. To assist you in locating the Map Styles editor, here is the link to Map Styles:https://console.cloud.google.com/google/maps-apis/studio/styles
To follow-up on this in an effort to assist you in bringing this bug to a resolution, please see the attached screenshot from the (old) Map Styles editor showing the issue and how you can duplicate it on your own. Similarly, the issue can also be duplicated in the (new) preview of the cloud-based Map Styles editor. Stroke color and width are not working as expected, for both the 3d and footprint style of buildings on the map. To assist you in locating the Map Styles editor, here is the link to Map Styles:
am...@google.com <am...@google.com> #5
Thank you for the information.
We have verified and logged this issue internally. Please note that we cannot give you any timelines, but you can star the issue to get notifications.
d....@gmail.com <d....@gmail.com> #6
Thank you for the update and for your help on this. I have stared this issue and will be watching for future updates.
d....@gmail.com <d....@gmail.com> #7
redacted
am...@google.com <am...@google.com> #8
redacted
d....@gmail.com <d....@gmail.com> #9
redacted
do...@gmail.com <do...@gmail.com> #10
I am not sure what the last 3 comments are above that were added today because I cannot view them (Restricted Content).
I did notice a recent change to the (new) cloud-based Map Styles editor which added the ability to edit the stroke color and width for the footprint style of buildings. That seems to be some positive progress.
I did notice a recent change to the (new) cloud-based Map Styles editor which added the ability to edit the stroke color and width for the footprint style of buildings. That seems to be some positive progress.
gi...@gmail.com <gi...@gmail.com> #11
<codes><312220318></codes>
tw...@gmail.com <tw...@gmail.com> #12
As I noted above, I noticed some minor positive progress on this bug fix. I am wondering if there are any official updates highlighting what has been fixed so far and what is currently being worked on or pending?
mr...@gmail.com <mr...@gmail.com> #13
Tested again today with the latest Map Styles editor, since it has had several recent updates, but unfortunately Stroke and Width for Buildings (3d and Footprint) are still not working as expected.
[Deleted User] <[Deleted User]> #14
Adding another issue that I noticed when testing again today. Building Fill color is missing the Transparency option. If I recall correctly, in the past, 3D Buildings automatically had some transparency to allow you to see the road names within the road strokes/lines/intersections through the buildings when the map is tilted. This is especially useful when viewing metropolitan areas with lots of large/tall buildings. Screenshot attached (Transparency-Issue-Expected.jpg).
Please add this to the list of bugs/issues that I have reported above: Building Fill color is missing the Transparency option.
Please add this to the list of bugs/issues that I have reported above: Building Fill color is missing the Transparency option.
[Deleted User] <[Deleted User]> #15
Back again to mention that I confirmed again today that all of these issues have persisted over into the new Cloud Based Map Styles Editor, so the bugs will all need to be addressed in the new Cloud Based Map Styles Editor and probably not in the old Map Styles Editor, which is scheduled to be retired early next year.
[Deleted User] <[Deleted User]> #16
Thank you for your message.
As per checking,
Our Engineering team is actively working on fixing the mentioned issues. We apologize for the delay and sincerely appreciate your understanding.
Rest assured that once we have receive any shareable updates, we'll let you know.
Thanks again.
[Deleted User] <[Deleted User]> #17
Glad to hear that the related issue in comment#14 doesn't actually seem to relate to the rest of these reported issues. Feel free to fork comment#14 off as it's own bug/issue report.
Description
Version used: 25.1.0
Theme used: Theme.AppCompat.Light.DarkActionBar
Devices/Android versions reproduced on: every devices I tested on, for example : Sony Xperia Z3 tablet, Samsung Galaxy Tab S2.
It seems related to other issues being reported about fragment replace transactions, but this one does not use the replace method.
Steps to reproduce :
- Add a fragment with a simple transaction :
getSupportFragmentManager()
.beginTransaction()
.setCustomAnimations(android.R.anim.fade_in, android.R.anim.fade_out)
.add(R.id.fragment_container, new TestFragment())
.commit()
- Remove the fragment using a simple remove, and just after start a new activity :
final Fragment fragment = getSupportFragmentManager().findFragmentById(R.id.fragment_container);
if (fragment != null) {
getSupportFragmentManager()
.beginTransaction()
.setCustomAnimations(android.R.anim.fade_in, android.R.anim.fade_out)
.remove(fragment)
.commit();
startActivity(new Intent(this, MainActivity.class));
}
- Go back to the old activity
What should happen : the fragment that was added should not be here anymore.
What happens : the fragment is still here. But the thing is it's only some sort of "ghost view" : it's impossible to reach it in debug using the view hierarchy. I even tried to activate the debug option "show layout bounds", which does not shows the bound on the fragment view. The view is not clickable, if I call removeAllViews() on the container it's still here.
Another thing : even with this view still here, if I re-add a fragment it will be added below the "ghost view". Everything works, but the old view is still here.
I attached a sample project to reproduce this issue. The "remove fragment" button is just here to validate the behaviour without starting another activity. You can see the bug using :
- "Add fragment"
- "Remove fragment and start activity"
- Press the back button
The old fragment is still here. If you press the add fragment button, another fragment will appear behing the old fragment, which should not be possible.
If you use the "show layout bounds" option, the bug is really visible :
- Start from scratch (kill the app)
- "Add fragment"
- Enable the "show layout bounds" option.
- "Remove fragment and start activity"
- Press the back button
Here everything seems normal except for the fragment still being here. But if you disable the "show layout bounds" option, the fragment view will stay unchanged, with layout bounds displayed. As if it were a cached view not recognized by the system.
I also attached a screenshot of this behavior. You can see the "show layout bounds" option is disabled, but it still shows on the fragment view.
All this does not happen with support lib 25.0.1.