| Issue 33115: | Sometimes <base> tags are ignored | |
| 3 people starred this issue and may be notified of changes. | Back to list |
Sign in to add a comment
|
Chrome Version : Google Chrome 4.0.249.49 (Official Build 35163) beta WebKit 532.5 V8 1.3.18.17 User Agent Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_8; en-US) AppleWebKit/532.5 (KHTML, like Gecko) Chrome/4.0.249.49 Safari/532.5 URLs (if applicable) : http://translate.google.com/translate? hl=en&sl=auto&tl=es&u=http://www.vancouver2010.com/ Other browsers tested: Add OK or FAIL after other browsers where you have tested this issue: Safari 4: OK Firefox 3.x: OK IE 7: ? IE 8: ? What steps will reproduce the problem? 1. Visit http://translate.google.com/translate? hl=en&sl=auto&tl=es&u=http://www.vancouver2010.com/ 2. The bottom frame on the page contains a translation of vancouver2010.com, which has a <base> tag so that the relative URLs refer to vancouver2010.com, not the host name we proxy the translation on. 3. Thus none of the images, css, or JS load. What is the expected result? All the relative URLed content should load correctly from www.vancouver2010.com What happens instead? None of the images, css, or JS load Note: this doesn't happen with all translated pages. For example: http://translate.google.com/translate?hl=en&sl=auto&tl=es&u=http://www.google.com/ That page contains a <base> tag as well, yet everything seems to load correctly. Please provide any additional information below. Attach a screenshot if possible.
,
Jan 26, 2010
Yep. :(
,
Jan 26, 2010
What's going on is the XSS filter is noticing that the <base> tag in the page appears in the URL of the page. That usually means an XSS attack is going on, but googleusercontent.com is fine with being XSSed. It's too bad we discovered this today as opposed to last week. I think we can fix this on our end. I'll try and see if we can get the fix merged to the stable branch.
Owner: aba...@chromium.org
Cc: -aba...@chromium.org
,
Jan 26, 2010
Interesting. Is there any quick fix we can do either in Google Translate or on vancouver2010.com to get this to work? I suppose having them not use relative paths would certainly fix things. Thanks, Josh
,
Feb 9, 2010
Note: this is fixed on trunk and in the Windows dev channel now (5.0.317.2). The fix has been merged to the Stable channel for windows (4.0.249.x) and will be shipped sometime this week.
Status: Fixed
Cc: anan...@chromium.org
,
Feb 9, 2010
Works fine with Google Chrome 4.0.249.89 (Official Build 38071) on Windows
Status: Verified
,
Feb 23, 2010
Layout broken problem has been resolved, but it seems the flash from vancouver2010.com could not be displayed properly under this case. See attached screen-shot for reference. Check in build 5.0.335.0 (Official Build 39561) and trunk 5.0.336.0 (Developer Build 39601)
Status: Assigned
,
Feb 23, 2010
Is this actually a Chrome bug? Or just a Google Translate bug. I see the same problem in Safari & Firefox on the Mac.
,
Feb 24, 2010
5.0.307.11 (Official Build 39572) beta I see the same results on Mac Chrome, Safari and Firefox.
Status: WontFix
|
||||||||||
| ► Sign in to add a comment | |||||||||||
Cc: aba...@chromium.org
Labels: -Area-Undefined Area-WebKit WebKit-Core OS-All Mstone-X