Do hit tests against Annots in reverse order.

Do hit tests against Annots in reverse order.

BUG=chromium:445408
R=jun_fang@foxitsoftware.com

Committed: https://pdfium.googlesource.com/pdfium/+/944ccad72d028ed5e37f53c5c8c0888866905bc3

[Lei Zhang, 2015-02-26 01:12:04]

thestig@chromium.org changed reviewers:
+ jun_fang@foxitsoftware.com, kai_jing@foxitsoftware.com

[Lei Zhang, 2015-02-26 01:12:04]

I can't find evidence to support this in the PDF spec, but all the other PDF
viewers seem to behave this way.

[jun_fang, 2015-02-27 01:57:42]

On 2015/02/26 01:12:04, Lei Zhang wrote:
> I can't find evidence to support this in the PDF spec, but all the other PDF
> viewers seem to behave this way.

LGTM. Seems that there is no a rule to define which action should be taken when
the overlapping area is selected.

[Lei Zhang, 2015-02-28 00:25:44]

On 2015/02/27 01:57:42, jun_fang wrote:
> On 2015/02/26 01:12:04, Lei Zhang wrote:
> > I can't find evidence to support this in the PDF spec, but all the other PDF
> > viewers seem to behave this way.
> 
> LGTM. Seems that there is no a rule to define which action should be taken
when
> the overlapping area is selected.

CPDF_InterForm::GetControlAtPoint() also works backwords through the
annotations. So this will make the two hit tests consistent.

The next thing I'm worried about is a page with two annotations that overlap,
but one is a link and the other is a form control widget. In such a case, I'm
concerned FPDPage_HasFormFieldAtPoint() and FPDFLink_GetLinkAtPoint() will both
return true for an overlapping point.

[Lei Zhang, 2015-02-28 00:29:58]

Committed patchset #2 (id:20001) manually as
944ccad72d028ed5e37f53c5c8c0888866905bc3 (presubmit successful).