Assigned
Status Update
Comments
tk...@chromium.org <tk...@chromium.org> #2
[Empty comment from Monorail migration]
fs...@opera.com <fs...@opera.com> #3
[Empty comment from Monorail migration]
bo...@chromium.org <bo...@chromium.org> #4
Sounds weird. I'm guessing you can't reproduce this on desktop chrome? In that case can you attach a small app demonstrating the problem?
Does anything stand out from devtools?https://developer.chrome.com/devtools/docs/remote-debugging#debugging-webviews
Does anything stand out from devtools?
ur...@gmail.com <ur...@gmail.com> #5
See the app attached. You can reproduce the issue when loading the file pot_withoutids.svg (see MainActivity.java line 20 resp. 21). The bubbles should go from bottom to the top - inside the pot, and not coming from the top left edge like meteorites ;-) If you load pot_withids.svg you can see how it should look like.
For splits of a second I can reproduce a similar behavior on desktop chrome as well. But I think that is another svg issue. If you load one of the contained svgs (does not matter which one), open another tab in chrome and switch between the tab where the svg is loaded and the another one, you should get sometimes again bubbles from outside the pot.
For splits of a second I can reproduce a similar behavior on desktop chrome as well. But I think that is another svg issue. If you load one of the contained svgs (does not matter which one), open another tab in chrome and switch between the tab where the svg is loaded and the another one, you should get sometimes again bubbles from outside the pot.
ur...@gmail.com <ur...@gmail.com> #6
One more thing to mention about the problem on desktop chrome. If you open the recent apps on android and go back again to the testapp, you can provoke the same issue as on desktop chrome when changing between tabs.
ur...@gmail.com <ur...@gmail.com> #7
Was anybody able to test the app and reproduce the issue?
ra...@chromium.org <ra...@chromium.org> #8
[Empty comment from Monorail migration]
sg...@chromium.org <sg...@chromium.org> #9
yes I checked it and as you mentioned I have both seen the issue in chrome for android (while switching the tabs bubbles come from outside momentarily) and in webview (bubbles always come from outside when using wihout_ids file). I am not aware of any SVG related code in webview.
sg...@chromium.org <sg...@chromium.org> #10
[Empty comment from Monorail migration]
sg...@chromium.org <sg...@chromium.org> #11
pdr@ any idea who can help us investigating the root reason?
pd...@chromium.org <pd...@chromium.org> #12
Can you reproduce this with an html or svg file and chrome on desktop/android without webview? I don't think we have any svg-specific code in webview.
Also, just a note: we are actively moving away from <animate> elements and will be deprecating them shortly:https://groups.google.com/a/chromium.org/d/msg/blink-dev/5o0yiO440LM/59rZqirUQNwJ . We should still look into this though.
Also, just a note: we are actively moving away from <animate> elements and will be deprecating them shortly:
sg...@chromium.org <sg...@chromium.org> #13
try the attached svg file in chrome for android. As noted above the problem is not reproducible unless you open another tab and switch between the current and the svg loaded ones. For a split second, you see the bubbles coming diagonally from outside.
I don't know if this has the same root cause with the webview issue.
I don't know if this has the same root cause with the webview issue.
to...@chromium.org <to...@chromium.org> #14
pdr@, did you ever get a chance to look at this (or find someone else who can?)
If the issue in chrome is the same as the webview problem then that would be nice ;)
If the issue in chrome is the same as the webview problem then that would be nice ;)
sh...@chromium.org <sh...@chromium.org> #15
This issue has been available for more than 365 days, and should be re-evaluated. Please re-triage this issue.
The Hotlist-Recharge-Cold label is applied for tracking purposes, and should not be removed after re-triaging the issue.
For more details visithttps://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
The Hotlist-Recharge-Cold label is applied for tracking purposes, and should not be removed after re-triaging the issue.
For more details visit
sc...@chromium.org <sc...@chromium.org> #16
Coming back to this on recharge.
On the WebView, how do you "read back again"? This seems to be a simple problem of inserting, or rather failing to insert, appropriate spacing in the string that is formed from the animateTransform node.
On the WebView, how do you "read back again"? This seems to be a simple problem of inserting, or rather failing to insert, appropriate spacing in the string that is formed from the animateTransform node.
fs...@opera.com <fs...@opera.com> #17
I'll note that there appears to be two fairly different issues at play here:
1) What's described in the original report, which seems to be a serialization issue. Information seems to be lacking on what entrypoint is used to perform the serialization.
2) c#4 (and on) which seems to be a SMIL issue (whether it be syncbase related or something else)
Is (1) just a red herring, or should this bug be split into two (seemingly quite different issues?)
1) What's described in the original report, which seems to be a serialization issue. Information seems to be lacking on what entrypoint is used to perform the serialization.
2) c#4 (and on) which seems to be a SMIL issue (whether it be syncbase related or something else)
Is (1) just a red herring, or should this bug be split into two (seemingly quite different issues?)
sc...@chromium.org <sc...@chromium.org> #18
I agree it is probably 2 issues, so the second could be different report. The difference in behavior is id attribute vs no id, so presumably that's a good starting point for figuring out what's wrong.
sg...@chromium.org <sg...@chromium.org> #19
bulk editing to assign, rather than available.
is...@google.com <is...@google.com> #20
This issue was migrated from crbug.com/chromium/469081?no_tracker_redirect=1
[Multiple monorail components: Blink>SVG, Mobile>WebView]
[Monorail components added to Component Tags custom field.]
[Multiple monorail components: Blink>SVG, Mobile>WebView]
[Monorail components added to Component Tags custom field.]
Description
<animateTransform attributeType="XML" attributeName="transform" type="translate" from="200 350" to="0 0" begin="0.8s; star1.end" dur="1.5s" fill="remove" />
If the data is read back again, the SVG tag looks like:
<animateTransformattributeType="XML"attributeName="transform"type="translate"from="200 350" to="0 0"begin="0.8s; star1.end" dur="1.5s"fill="remove"/>
This leads to ignoring of the "invalid" svg tag, what corrupts the SVG animation.
When using an ID:
<animateTransform id="myID" attributeType="XML" attributeName="transform" type="scale" from="0.2 0.2" to="1 1" begin="0.8s; star1.end" dur="1.5s" additive="replace" fill="remove"/>
read back:
<animateTransform id="myID"attributeType="XML"attributeName="transform"type="scale"from="0.2 0.2" to="1 1"begin="0.8s; star1.end" dur="1.5s"additive="replace" fill="remove"/>
As soon as an id attribute is provided, the tag name stays. This happens on Android 4.4 and Android 5.0.