I'm not sure whether any step I've missed to switch on *physical-web* feature.
In case, this is a duplicate issue please ignore.


Moreover, the excerpt below from "dumpstate_app_error.*", looks like its trying to handle link click & launch an activity (i.e. startActivity()) using application context instead of an activity instance and that would have resulted into FATAL.

[Stack trace]
09-28 18:40:20.795  9957  9957 D AndroidRuntime: Shutting down VM
09-28 18:40:20.795  9957  9957 E AndroidRuntime: FATAL EXCEPTION: main
09-28 18:40:20.795  9957  9957 E AndroidRuntime: Process: org.chromium.chrome, PID: 9957
09-28 18:40:20.795  9957  9957 E AndroidRuntime: android.util.AndroidRuntimeException: Calling startActivity() from outside of an Activity  context requires the FLAG_ACTIVITY_NEW_TASK flag. Is this really what you want?
09-28 18:40:20.795  9957  9957 E AndroidRuntime: 	at android.app.ContextImpl.startActivity(ContextImpl.java:1540)
09-28 18:40:20.795  9957  9957 E AndroidRuntime: 	at android.app.ContextImpl.startActivity(ContextImpl.java:1527)
09-28 18:40:20.795  9957  9957 E AndroidRuntime: 	at android.content.ContextWrapper.startActivity(ContextWrapper.java:337)
09-28 18:40:20.795  9957  9957 E AndroidRuntime: 	at org.chromium.chrome.browser.physicalweb.PhysicalWebDiagnosticsPage$1.onClick(PhysicalWebDiagnosticsPage.java:66)
09-28 18:40:20.795  9957  9957 E AndroidRuntime: 	at android.view.View.performClick(View.java:5156)
09-28 18:40:20.795  9957  9957 E AndroidRuntime: 	at android.view.View$PerformClick.run(View.java:20755)
09-28 18:40:20.795  9957  9957 E AndroidRuntime: 	at android.os.Handler.handleCallback(Handler.java:739)
09-28 18:40:20.795  9957  9957 E AndroidRuntime: 	at android.os.Handler.dispatchMessage(Handler.java:95)
09-28 18:40:20.795  9957  9957 E AndroidRuntime: 	at android.os.Looper.loop(Looper.java:145)
09-28 18:40:20.795  9957  9957 E AndroidRuntime: 	at android.app.ActivityThread.main(ActivityThread.java:5832)
09-28 18:40:20.795  9957  9957 E AndroidRuntime: 	at java.lang.reflect.Method.invoke(Native Method)
09-28 18:40:20.795  9957  9957 E AndroidRuntime: 	at java.lang.reflect.Method.invoke(Method.java:372)
09-28 18:40:20.795  9957  9957 E AndroidRuntime: 	at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:1399)
09-28 18:40:20.795  9957  9957 E AndroidRuntime: 	at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1194)


A recommended way to solve this problem is to cache the activity reference and use it to startActivity() instead of app context.  

A lesser recommended solution would be to supply an additional flag *FLAG_ACTIVITY_NEW_TASK* along the intent to startActivity().

I've tried below patch to avoid this crash.

diff --git a/chrome/android/java/src/org/chromium/chrome/browser/physicalweb/PhysicalWebDiagnosticsPage.java b/chrome/android/java/src/org/chromium/chrome/browser/physicalweb/P
index 32a7d7a..0629a62 100644
--- a/chrome/android/java/src/org/chromium/chrome/browser/physicalweb/PhysicalWebDiagnosticsPage.java
+++ b/chrome/android/java/src/org/chromium/chrome/browser/physicalweb/PhysicalWebDiagnosticsPage.java
@@ -216,8 +216,10 @@ public class PhysicalWebDiagnosticsPage extends BasicNativePage {
     }
 
     private static Intent createListUrlsIntent() {
-        return new Intent(ContextUtils.getApplicationContext(), ListUrlsActivity.class)
-                .putExtra(ListUrlsActivity.REFERER_KEY, ListUrlsActivity.DIAGNOSTICS_REFERER);
+        Intent intent = new Intent(ContextUtils.getApplicationContext(), ListUrlsActivity.class);
+        intent.addFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
+        intent.putExtra(ListUrlsActivity.REFERER_KEY, ListUrlsActivity.DIAGNOSTICS_REFERER);
+        return intent;
     }
 
     private static String colorToHexValue(int color) {

Did you ever receive a notification to opt into Physical Web? Since oyu have location + bluetooth on, you should've received it when you were first near a beacon (it'll be a higher priority, buzzing notification)

The step you are missing is to go to settings->privacy->physical web->switch on

There's an activity in scope when we create the onClickListener...it should be easy enough to use the activity rather than the application context.  Thanks for the report!

Thanks animohan@ & cco3@ for reply.

With just *location + Bluetooth on*, I didn't receive any notification, as I move near to beacon's proximity.

With "settings->privacy->physical web->switch on", the Physical Web diagnostics page shows status as *Physical Web is ON*.

I'll try to use the |activity| to start ListUrlsActivity to fix this crash.
Thanks!

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

commit d67018f2cc74b4763205465fff5dc4ac31ab9103
Author: hayesjordan <hayesjordan@google.com>
Date: Wed Sep 28 20:46:15 2016

Fix crash when clicking BROWSE THE PHYSICAL WEB

When the enable-physical-web flag is enabled but the setting under
settings->privacy->physical web is off, the user can cause chrome to
crash by going to chrome://physical-web and clicking the "BROWSE THE
PHYSICAL WEB" button.

BUG= 651076 

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

[modify] https://crrev.com/d67018f2cc74b4763205465fff5dc4ac31ab9103/chrome/android/java/src/org/chromium/chrome/browser/physicalweb/PhysicalWebDiagnosticsPage.java

Issue 654572 has been merged into this issue.

[Automated comment] Less than 2 weeks to go before stable on M54, manual review required.

If one of the prerequisites (like Bluetooth) is disabled and Physical Web status is off, doesn't it make sense to disable the "Browse the Physical Web" button. As I see now, it is enabled even when Physical Web status is Off.

Yes, it'd be good to do that.  That can be done in a different change.

Since this only manifests on an internal page (about:physical-web) I'm not going to block the M54 stable release on it - cco3@ agreed over chat, animohan@ please correct us if you disagree.

That said, given how safe the merge for this would be, please go ahead and merge in the next day or two if you want this fix included in the M54 stable release.  Merge approved for M54 branch 2840.

+1 -- I'm ok with not blocking on this

I don't have committer status, but this is the command:
git drover --branch 2840 --cherry-pick d67018f2cc74b4763205465fff5dc4ac31ab9103

Alex, would you be willing to land it?

Merged!  (bugdroid should catch up soon).

Thank you!

This was already merged.