Revert "Finding an <object> element by name only works it has no children other than <param> elemen…

Revert "Finding an <object> element by name only works it has no children other than <param> elements"

This reverts commit 0e0a6fd6f7b0f1b34c474e785068eb5e59f6ceb3.
It broke some websites, including http://map.d.co.il where the map no longer shows up.

R=tkent
BUG=319662
Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=162435

[tkent, 2013-11-21 01:51:13]

lgtm.

I don't think we should give up the correct behavior only for one site. However
there might be a lot of affected sites.

Can we add a deprecation warning for this? (If we add the warning, it should be
done by a separated patch.)

[commit-bot: I haz the power, 2013-11-21 01:53:52]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/ch.dumez@samsung.com/61213008/1

[commit-bot: I haz the power, 2013-11-21 03:40:24]

Change committed as 162435

[Inactive, 2013-11-21 04:06:14]

On 2013/11/21 01:51:13, tkent wrote:
> lgtm.
> 
> I don't think we should give up the correct behavior only for one site.
However
> there might be a lot of affected sites.
> 
> Can we add a deprecation warning for this? (If we add the warning, it should
be
> done by a separated patch.)

I unfortunately did not have much time to investigate that one yet but I did see
a difference in behavior with Firefox. Firefox was returning only the embed
element and chrome was returning the embed and the object. This is weird because
I remember testing Firefox and IE when writing this patch.

I will take another look at this when I get some spare time and work on another
proposal.

In the meantime, reverting is definitely the safest.

[sof, 2013-12-05 08:00:01]

On 2013/11/21 04:06:14, Chris Dumez wrote:
> On 2013/11/21 01:51:13, tkent wrote:
> > lgtm.
> > 
> > I don't think we should give up the correct behavior only for one site.
> However
> > there might be a lot of affected sites.
> > 
> > Can we add a deprecation warning for this? (If we add the warning, it should
> be
> > done by a separated patch.)
> 
> I unfortunately did not have much time to investigate that one yet but I did
see
> a difference in behavior with Firefox. Firefox was returning only the embed
> element and chrome was returning the embed and the object. This is weird
because
> I remember testing Firefox and IE when writing this patch.
> 
> I will take another look at this when I get some spare time and work on
another
> proposal.
> 
> In the meantime, reverting is definitely the safest.

Why this revert & ok given that https://codereview.chromium.org/75273004/ was
in-flight at the time?

[tkent, 2013-12-05 23:47:47]

On 2013/12/05 08:00:01, sof wrote:
> Why this revert & ok given that https://codereview.chromium.org/75273004/ was
> in-flight at the time?

Reverting is much safer than fixing. I'm not sure if your patch fixes
crbug.com/319662.