Above issue is not reproducible on Chromium builds hence providing Manual regression range and Change log URL: 

Good build: 53.0.2753.0
Bad build: 53.0.2754.0 

Change log URL:
https://chromium.googlesource.com/chromium/src/+log/53.0.2753.0..53.0.2754.0?pretty=fuller&n=10000

Suspecting: r396898 ?

@mastiz: Kindly help to reassign, if your changes are not related to this issue.

Note: This issue is also reproducible on Mac(10.10.5, 10.11.4) and Linux(14.04 LTS) OS.

Kindly review the attached screen-cast for reference.

Deleted: Tooltip Screenshot.png 12.6 KB

	Tooltip Screenshot.png 12.6 KB View Download

Deleted: Tooltip_Actual.mp4 750 KB

	Tooltip_Actual.mp4 750 KB View Download

Deleted: Tooltip_Expected.mp4 421 KB

	Tooltip_Expected.mp4 421 KB View Download

It is very unlikely that the suggested patch causes this regression and I didn't spot anything obvious in the changelog. Reassigning to reporter.

@erg: Kindly please take a look into this issue and please help to reassign to appropriate developer if your changes are not related to this issue.

Suspecting: r396977 ? from change log URL.

Adding RB label as this is a recent regression.

Can't reproduce on ToT on Linux; tooltips show.

(I also don't understand why you think a revert patch is to blame.)

With response to comment #5: Retested the above issue on Windows(7,8,10), Mac (10.10.5)(10.11.4) and Linux(Ubuntu 14.04 LTS) OS using Latest Canary chrome version 53.0.2767.4 (Official Build). It's still reproducible.

Note: 
1. This issue is not reproducible on Chromium builds. It's only reproducible on Chrome builds.
2. To reproduce the issue, Take a new user and then follow the steps which is mentioned in the bug.

Attaching screen-cast for reference.

Deleted: Latest Canary behavior.mp4 714 KB

	Latest Canary behavior.mp4 714 KB View Download

Adding Needs-Triage label, could someone please help us to fian on owner for this issue.

Thanks.!

possible suspect from the above comment # 1.

Suspect : https://codereview.chromium.org/2007133006
mahmadi@ : Could you please take a look into this if its related to your change.Else please help finding an appropriate owner for this.

Thanks in advance..!

tsergeant@ could you please take a look?

I am also unable to reproduce the behavior seen in the original report on Linux 53.0.2767.4 (Official Build) dev, or on latest Windows Canary.

As already mentioned, there's nothing in the changelog that looks like a likely culprit, and nobody else outside of the original reporter seems to have reproduced the bug.

I would suggest rerunning the bisect to see if there are any other clues there. 

With response to comment #10: Again, retested the above issue on multiple machine (Windows(7,8), Mac (10.10.5)(10.11.4) and Linux(Ubuntu 14.04 LTS)) using Latest Canary chrome version # 53.0.2773.0 (Official Build). It's still reproducible from our end.

Note: 
1. This issue is not reproducible on "Windows-10" machine.
2. Unable to provide the bisect info as this issue is not reproducible on Chromium builds also. hence providing manual regression range.

Manual regression range:
Good build: 53.0.2753.0
Bad build: 53.0.2754.0 

To reproduce the issue please follow the following steps:
1. Freshly installed the chrome or take a new user.
2. Go to NTP and give Print command.
3. Now hover the mouse pointer on Preview options and observe.

@tsergeant: Kindly take a look into this.

Attaching screen-cast for the reference.

Deleted: LatestCanary_behavior.mp4 634 KB

	LatestCanary_behavior.mp4 634 KB View Download

Able to repro the issue on mac 10.11.5 chrome version 53.0.2773.0 with the steps in comment #11

Please find the screencast

Deleted: 619465.mov 5.3 MB

619465.mov 5.3 MB Download

Okay, I'm able to reproduce locally.

The exact error is that the chrome.resourcesPrivate API which is used to get the localised strings isn't available to the PDF viewer for some reason? Something might have changed to do with API permissions.

I'm running a fine-grained bisect on local official builds to try and find a culprit CL.

My bisect has finished. Last good revision is R396859, which leaves R396860 ("[Origin Trials] Install origin trial bindings on V8 context conditionally") as the culprit. This seems a little unusual, but I've double checked the results and they've been consistent.

Assigning to iclelland@, as the author of that CL, to investigate further.

As a recap of the above:

1. This only reproduces on Chrome-branded builds. Adding "is_chrome_branded = true" to gn builds works by itself, no need for "is_official_build = true".

2. This only reproduces on new profiles. It seems like at some point something in the profile initialises itself correctly, and the bug goes away.

Given the above (particularly number 2), I'm lowering the priority of this bug.

That's really strange; I wouldn't expect any interaction at all between those two features, but I'll definitely take a look.

Does this happen on all new profiles, or just new installs (with no pre-existing config directory)?

Just a new profile, no need for a new user data dir.

(It's possible to have multiple windows open at once from the same Chrome binary, one with a profile which exhibits the bug and one with a profile which doesn't)

I can reproduce this on ToT, with a new user data dir consistently (it's less consistent with just a new profile, once the first profile is working).

Interestingly, it does *not* occur if I test without a network connection. In that case, the tooltips always appear correctly.

I wonder if there's some issue with the component updater still being in progress on new profiles that temporarily removes the PDF Viewer extension from the whitelist for the resourcesPrivate API?

I'm still looking to see when and how that API gets bound to the V8 context, to have some idea what I'm looking for, but given the behaviour in #14 (number 2), I'm suspecting some oddness involving Omaha and whitelists.

iclelland@ : Could you please update further on this.As the issue still seen on latest canary 54.0.2787.0.

It looks like the OriginTrialsContext::initializePendingFeatures method is being called for extensions, (where there should be no origin trials at all), and this is somehow interfering with the injection of the chrome.resourcesPrivate API. I'm still not 100% certain how exactly it is interfering, but I'm testing a simple fix that should stop that method from doing anything when there are no origin trial tokens present.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/a9b70a69ed18c1ba22b9270741e5368db816bc7a

commit a9b70a69ed18c1ba22b9270741e5368db816bc7a
Author: iclelland <iclelland@chromium.org>
Date: Thu Jul 07 19:15:27 2016

[OriginTrials] Don't attempt to initialize origin trials in isolated worlds.

This fixes an issue where calling ScriptState::forMainWorld within an
extension would sometimes interfere with registration of some private APIs.

BUG= 619465 

Review-Url: https://codereview.chromium.org/2122063002
Cr-Commit-Position: refs/heads/master@{#404204}

[modify] https://crrev.com/a9b70a69ed18c1ba22b9270741e5368db816bc7a/third_party/WebKit/Source/bindings/core/v8/WindowProxy.cpp

This should be fixed now, with the patch in #20. Can you check again when it hits canary?

Retested the above issue on Windows-7 machine using canary 54.0.2793.0 (Official Build). It's seems to be fixed and working as intended.

Closing as fixed. Feel free to move to verified if you're satisfied that it the fix is sufficient.