Fossil Forum


Hamburger menu problems

By btiffin on 2018-09-20 06:50:49 and edited on 2018-09-20 16:30:49 [link]

Just started happening the other night.

Using Seamonkey, NoScript turned off, many Hamburger menu items point to the honeypot (visible in the bottom message area when hovering over the menu items). This is from

Using Firefox fresh install, no extensions, menu items lead to the please enable javascript honeypot.

Visit the Timeline page, dropdown menu items then lead to the appropriate place.

Open a new tab, from the main menu items:

  • Home page, hamburger items busted.
  • Timeline, hamburger menu works.
  • Docs, broken.
  • Code, works.
  • Forum, while in this page, forum/forumnew, menu items lead to honeypot.
    • Forum start page, forum/forum, works.
  • Download page, busted.

And proof that javascript is running, the menu drops down each and every time, but leads to the honeypot (as seen in the bottom message of the browser - and by trying some by clicking) about half the time as listed above.

Log in as anonymous, everything works as expected. Log out (from the Docs page when I tried) and then it goes back to broken.

By veedeehjay on 2018-09-20 08:47:13 [link]

I see the same or similar:

I get the "Please enable javascript or log in to see this content" message for assorted pages on `', _independent_ of whether being logged in or not. other pages work just fine.  one example of non-working page:  "List of All Commands and Web Pages". of course, javascript _is_ enabled.

seen with `vivaldi' browser (uses the chrome engine)

By wyoung on 2018-09-20 10:11:17 [link]

This is happening because P("popup") is false in src/sitemap.c when you're not logged in.

I've checked, and popup form data is still being sent in this case, so I'm at a loss as to why the sitemap code can't see this flag. This is getting way down into the guts of how Fossil handles form data, so drh may have to deal with this.

If you need this fixed on your own repository, you can temporarily revert this checkin, which I thought was redundant with respect to the new popup=1 server-side code. Apparently not.

I'm guessing that what happened recently to cause this to start happening is that drh updated the skin on the server side to a version after that checkin.

By drh on 2018-09-20 10:41:39 [link]

Fixed by The previous check-in is an alternative fix, but the second check-in seems like a better solution to me, at the moment.

By wyoung on 2018-09-20 10:45:03 [link]

the second check-in seems like a better solution to me

Ditto. Thank you for tracking this down.

By btiffin on 2018-09-20 16:38:57 and edited on 2018-09-20 16:47:02 [link]

This project is awesome. :-)

Report an issue late at night, look again, fixes in the works. Nice.

Have good, make hamburgers